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: Maxwell Lol on 25 Jan 2010 12:32 frank <frank(a)example.invalid> writes: >>> gcc -dM -E - < /dev/null > It certainly does. Can we talk about the hyphen in the middle that > doesn't seem to do anything? > -- gcc normally taks a source code file, like prog.c, as an argument. The use of a hyphen where a program normally takes a filename as an argument, often means use STDIN instead of a filename. And since STDIN is now /dev/null (or the empty file), gcc reads no source code at all. So then it does as the rest of the arguments suggest - print out preprocessor flags that arer ALWAYS defined. In this case, it's a good idea to execute the command and see what happens. In this case, it prints out a bunch of preprocessor variables that are always defined based on your version of gcc, and the system architecture. For example #define linux 1 #define __WCHAR_TYPE__ int #define __SIZEOF_FLOAT__ 4 #define __INT_MAX__ 2147483647 #define __amd64__ 1 Which says I'm on a linux system, AMD CPU, wide characters are type "int", maximum size of an integer, etc. Based on these values, a C program can better define data structures, and macros.
From: Stephane CHAZELAS on 25 Jan 2010 14:25 2010-01-24, 22:26(-07), frank: > 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? [...] As already been said, "-" is a way to say "use stdin" and < /dev/null makes stdin /dev/null. Now one may wonder why we didn't use gcc -dM -E /dev/null The thing is, with that syntax, gcc doesn't know which language the file is written in as it has no extension. "-" has no extension either but for some reason, gcc seems to assume "c". So you need: gcc -dM -E -x c /dev/null I would tend to prefer that latter syntax, as you make it clear which language you want to know pre-defined macros for. Rather than relying on the undocumented (well, at least I couldn't find the documentation) fact that C is assumed for "-". -- St�phane
From: David W. Hodgins on 25 Jan 2010 14:38 On Mon, 25 Jan 2010 03:13:52 -0500, frank <frank(a)example.invalid> wrote: > It certainly does. Can we talk about the hyphen in the middle that > doesn't seem to do anything? For many programs, using a hyphen where a filename is expected tells the program to use stdin or stdout (depending on whether the filename is an input, or output file), rather then using a disk file. The redirect of stdin to come from /dev/null, has the same affect that pressing the enter key, to provide an empty input, would have. Regards, Dave Hodgins -- Change nomail.afraid.org to ody.ca to reply by email. (nomail.afraid.org has been set up specifically for use in usenet. Feel free to use it yourself.)
From: Ben Bacarisse on 25 Jan 2010 18:50 "David W. Hodgins" <dwhodgins(a)nomail.afraid.org> writes: > On Mon, 25 Jan 2010 03:13:52 -0500, frank <frank(a)example.invalid> wrote: > >> It certainly does. Can we talk about the hyphen in the middle that >> doesn't seem to do anything? > > For many programs, using a hyphen where a filename is expected tells > the program to use stdin or stdout (depending on whether the filename > is an input, or output file), rather then using a disk file. > > The redirect of stdin to come from /dev/null, has the same affect > that pressing the enter key, to provide an empty input, would > have. More like the effect of typing ^D (Control-D) -- if the tty interprets ^D as an EOF request, that is. -- Ben.
From: Keith Thompson on 25 Jan 2010 20:17
frank <frank(a)example.invalid> writes: > Seebs wrote: [...] >> 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. > > 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. gcc is free software, so "ordinary mortals" are free to look at anything they like. But this particular detail is probably "under the hood" in the sense that you don't need to now about it to do useful work, and if you do happen to know about it there's probably no real benefit in depending on the information. In any case, it sounds like you're assuming that gcc obtains the definitions for these macros by reading some hidden "whatever.h" file containing a bunch of #include directives. As far as I know, that's not the case; I think gcc does it internally. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" |