Vincent Lefevre wrote: > Under Mac OS X, with tail 5.92 installed by DarwinPorts: > > prunille:~> echo abcd > blah > prunille:~> /opt/local/bin/gtail -c 2 blah > /opt/local/bin/gtail: cannot open `2' for reading: No such file or directory > ==> blah <== > abcd > zsh: exit 1 /opt/local/bin/gtail -c 2 blah > prunille:~[1]> /opt/local/bin/gtail --version > tail (GNU coreutils) 5.92 > [...]
Thanks for the report. This works for me on my GNU/Linux machine. I am guessing that configure is somehow not configuring the getopt routine properly. It may be deducing that getopt_long is available and functional when it is not. What is the output of grep on getopt from the config.log file? For example I have the following output. grep getopt config.log configure:26757: checking getopt.h usability configure:26801: checking getopt.h presence configure:26872: checking for getopt.h configure:26901: checking for getopt_long_only | #include <getopt.h> configure:27066: checking for working GNU getopt function ac_cv_func_getopt_long_only=yes ac_cv_header_getopt_h=yes gl_cv_func_gnu_getopt=yes What is the output of grep on the config.h file? For example I have the following output. grep GETOPT config.h #define HAVE_GETOPT_H 1 #define HAVE_GETOPT_LONG_ONLY 1 /* #undef __GETOPT_PREFIX */ Would it be possible for you to get in the debugger and determine where this goes astray and why it is not parsing the -c option correctly? Bob _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
