interpreting a unix command I
in [Shell]
|
Prev: How to run multiple commands in -exec of find command
Next: Finding the largest files in a filesystem (or highest values in a list) quickly
From: frank on 25 Jan 2010 00:26 Hello newsgroup, I'm relatively new to linux and have yet to put it through its paces properly, but I keep pecking away at it. I'm looking for a precise description of what's going on here: gcc -dM -E - < /dev/null Let me bust up the question a bit: gcc : invokes compiler -dM : show all the macros from preprocessing -E : stop after preprocessor - : no idea what a hyphen is doing here < : redirecting /dev/null/ : the bitbucket why would any macro be defined here? Thanks for your comment and cheers, -- frank
From: Ben Finney on 25 Jan 2010 00:57 frank <frank(a)example.invalid> writes: > I'm relatively new to linux and have yet to put it through its paces > properly, but I keep pecking away at it. Congratulations on your motivation to persist and learn. > I'm looking for a precise description of what's going on here: > > gcc -dM -E - < /dev/null The shell — I will assume Bash 4.1 — is going to parse that into several layers. I won't go through the parsing algorithm it uses (but it *is* documented, and is worth your while to learn so you can know what to expect from a given command line). The end result will be: gcc -dM -E - # a single command < # a redirection operator /dev/null # the argument to the '<' operator You can consult the 'gcc(1)' man page for the single command; the rest (the redirection) is going to be completely invisible to 'gcc' once it actually runs. What will happen is the command will run in a separate process, but before that process starts, Bash will (because the '<' operator was used) change the “standard input” file handle so that it is connected to the file named by '/dev/null'. The files under '/dev/' are almost entirely not normal files; they are known as “device special” files, and will show up in 'ls -l' with a 'b' or 'c' in the leftmost column. They represent, not files on disk, but some kernel-provided device. Often they are an interface to some hardware or service. In the case of '/dev/null', it's a kernel-provided service that, when read, is always empty; and, when written, accepts any input given and throws it away. So what this construct, '< /dev/null', represents is a way to feed an always-available but always-empty file to a process that expects some data on standard input. You will likely find, when you read the 'gcc(1)' man page, that the '-' argument is specifying that the program's main input is to be read from the process's standard input, instead of a named file. It's a point important enough to repeat: The redirection is handled entirely by Bash when it starts the 'gcc' process. The 'gcc' process will know nothing about the '< /dev/null' part of the command-line. It will only see 'gcc -dM -E -' as its command, and will read whatever comes in on its standard input. Hope that helps. -- \ “True greatness is measured by how much freedom you give to | `\ others, not by how much you can coerce others to do what you | _o__) want.” —Larry Wall | Ben Finney
From: Seebs on 25 Jan 2010 01:56 On 2010-01-25, frank <frank(a)example.invalid> wrote: > I'm relatively new to linux and have yet to put it through its paces > properly, but I keep pecking away at it. I'm looking for a precise > description of what's going on here: This probably really wants gnu.gcc.help -- it's really very little to do with the shell. > gcc -dM -E - < /dev/null > Let me bust up the question a bit: > gcc : invokes compiler > -dM : show all the macros from preprocessing > -E : stop after preprocessor > - : no idea what a hyphen is doing here >< : redirecting > /dev/null/ : the bitbucket why would any macro be defined here? It wouldn't. However, there are *predefined* macros that gcc defines, before it encounters anything, so invoking gcc this way on an empty file (/dev/null is empty on read) produces a list of precisely those values that were defined before it had read any input. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: frank on 25 Jan 2010 03:13 Ben Finney wrote: > frank <frank(a)example.invalid> writes: > >> I'm relatively new to linux and have yet to put it through its paces >> properly, but I keep pecking away at it. > > Congratulations on your motivation to persist and learn. > >> I'm looking for a precise description of what's going on here: >> >> gcc -dM -E - < /dev/null > > The shell — I will assume Bash 4.1 — is going to parse that into several > layers. I won't go through the parsing algorithm it uses (but it *is* > documented, and is worth your while to learn so you can know what to > expect from a given command line). > > The end result will be: > > gcc -dM -E - # a single command > < # a redirection operator > /dev/null # the argument to the '<' operator > > You can consult the 'gcc(1)' man page for the single command; the rest > (the redirection) is going to be completely invisible to 'gcc' once it > actually runs. > > What will happen is the command will run in a separate process, but > before that process starts, Bash will (because the '<' operator was > used) change the “standard input” file handle so that it is connected to > the file named by '/dev/null'. > > The files under '/dev/' are almost entirely not normal files; they are > known as “device special” files, and will show up in 'ls -l' with a 'b' > or 'c' in the leftmost column. They represent, not files on disk, but > some kernel-provided device. Often they are an interface to some > hardware or service. > > In the case of '/dev/null', it's a kernel-provided service that, when > read, is always empty; and, when written, accepts any input given and > throws it away. > > So what this construct, '< /dev/null', represents is a way to feed an > always-available but always-empty file to a process that expects some > data on standard input. > > You will likely find, when you read the 'gcc(1)' man page, that the '-' > argument is specifying that the program's main input is to be read from > the process's standard input, instead of a named file. > > It's a point important enough to repeat: The redirection is handled > entirely by Bash when it starts the 'gcc' process. The 'gcc' process > will know nothing about the '< /dev/null' part of the command-line. It > will only see 'gcc -dM -E -' as its command, and will read whatever > comes in on its standard input. > > Hope that helps. > It certainly does. Can we talk about the hyphen in the middle that doesn't seem to do anything? -- frank
From: frank on 25 Jan 2010 03:20
Seebs wrote: > On 2010-01-25, frank <frank(a)example.invalid> wrote: >> I'm relatively new to linux and have yet to put it through its paces >> properly, but I keep pecking away at it. I'm looking for a precise >> description of what's going on here: > > This probably really wants gnu.gcc.help -- it's really very little to do with > the shell. Maybe I should have x-posted. > >> gcc -dM -E - < /dev/null > >> Let me bust up the question a bit: >> gcc : invokes compiler >> -dM : show all the macros from preprocessing >> -E : stop after preprocessor >> - : no idea what a hyphen is doing here >> < : redirecting >> /dev/null/ : the bitbucket why would any macro be defined here? > > It wouldn't. > > However, there are *predefined* macros that gcc defines, before it > encounters anything, so invoking gcc this way on an empty file (/dev/null > is empty on read) produces a list of precisely those values that were > defined before it had read any input. > > -s Ok, cool. Is it for ordinary mortals to know the files that gcc uses to obtain these macros or is it underneath the hood? I've been reading gccint today, and the information I'm asking for is probably in there, but I've got a lot of reading to do there if I'm to get something useful out of it. -- frank |