Hello!

I am studying a script and one line says:

clogin -t $timeo -c \"$cisco_cmds\" $host </dev/null > $host.raw 2>&1

I don't undestand the meaning of the "</dev/null" sentence.

I understand this:

> /dev/null

It's redirecting the output to the blackhole file.

But with "<" what could mean?

Thanks!

Hi there,

that means exactly the opposite: Take the input for the command line from /dev/null.

[X] Doc CPU

Ok. But what could be the purpose to do that, considering that nothing (for the mere mortal) is inside /dev/null?

It's handy in the event that you need a dummy input. For example, if you have a program that normally requires some input from STDIN, you can redirect /dev/null as an input file in order to trick the program into thinking it has an input.

One example of this kind of trick is inspecting GCC's behavior; passing /dev/null as an input file allows one to examine quite a bit of GCC's steps in compilation without actually compliling anything.

However, there's a much more important use for this kind of redirection: running a daemon.

See, part of a daemon's operation involves detaching itself from its parent shell process (or some other process it's the child of, like a webserver). Part of this includes detaching itself from said shell by redirecting STDIN, STDERR, and STDOUT to alternate filehandles. /dev/null is commonly used for STDIN, while STDOUT and STDERR may be redirected to /dev/null and/or some logfile.

Most daemons will do this on their own (since most languages support closing and re-opening STDIO filehandles). However, if you're trying to daemonize a program that doesn't daemonize itself (either it's meant to have a controlling terminal or it otherwise doesn't daemonize on its own for some reason), you'll want to make sure that STDIN, STDOUT, and STDERR are detached from the shell. That's where the </dev/null bit comes in.

Note that there are other tasks involved in daemonization, too. However, I imagine this is the context that you'd most often see /dev/null redirected to STDIN.

What it causes is the application to get a "end of file" condition on stdin as soon as it reads from stdin.

Studiyng the script it could be the EOF condition mentioned by jpollard.

Not sure.

I am gonna study the daemon thing too.

Thanks all!!!

The daemon thing is most unlikely - as you can't really get a daemon that way. All you get is a process without stdin/stdout/stderr connected to a terminal.

That doesn't create a daemon because becoming a daemon requires the "controlling terminal" to be disconnected (and it isn't - it requires a "setsid" system call though you CAN use a setsid command that does that before executing a command ("setsid command_to_run_new_session parameters...").

That's what I was trying to get at in my explanation: it's not the only thing to do if a process needs to become a daemon, but it's one of them. As you mentioned, yes, some kind of call to setsid() (either via a command or - if you're writing the program yourself - using the appropriate language-specific calls) is also necessary.