bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: timeout --help --help


From: Pádraig Brady
Subject: Re: timeout --help --help
Date: Mon, 22 Mar 2010 10:18:59 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

On 22/03/10 09:31, Kim Hansen wrote:
> 2010/3/22 Pádraig Brady <address@hidden>:
>> On 21/03/10 16:16, Kim Hansen wrote:
>>> When testing the --kill-after I found the following strange behaviour:
>>>   address@hidden:~$ timeout --help --help
>>>   timeout: unrecognized option '--help'
>>>   Try `timeout --help' for more information.
>>>   address@hidden:~$
>>>
>>> It looks like parse_long_options() only will give help or version if
>>> that is the only option passed to the program, the following change
>>> made the program behave like I expected it to do:
>>
>> Well all of the following have that behavior:
>>
>> $ grep -l parse_long_options *.c | sed 's/.c$//' | fmt
>> basename chroot cksum dd dirname echo expr getlimits hostid hostname
>> link logname nice nohup printf setuidgid sleep sync test timeout tsort
>> unlink uptime users whoami yes
> 
> But all the programs that I sometimes need help for does it the other way:
> 
> address@hidden:/tmp/coreutils/git/src$ grep -l GETOPT_HELP_OPTION_DECL *.c |
> sed 's/.c$//' | fmt
> base64 cat chcon chgrp chmod chown chroot comm cp csplit cut date df
> dircolors du env expand factor fmt fold groups head id install join
> kill ln ls md5sum mkdir mkfifo mknod mktemp mv nl nproc od paste pathchk
> pinky pr printenv ptx pwd readlink rm rmdir runcon seq shred shuf sort
> split stat stdbuf stty su sum tac tail tee timeout touch tr truncate
> tty uname unexpand uniq wc who
> 
> chroot is a little funny, it does both.

Yes, that should probably be normalized.

>> The reason is that parse_long_options() only parses
>> options when there is a single option passed to the command.
>> It does this on purpose so as not to effect options that
>> may be passed on to further commands or requiring users
>> to specially mark such options.
> 
> I don't think I understand this, can you give an example?
> 
> I would expect it to be enough that timeout uses a + at the start of
> the getopt string, and it seems to work: "./timeout 1s cat --version"
> returns the version of cat, not of timeout.

True, '+' negates that argument.
So perhaps parse_long_options is just a shortcut for commands
that don't have to process their own options?

$ grep -l parse_long_options *.c | xargs grep "getopt_long ("
basename.c:  if (getopt_long (argc, argv, "+", NULL, NULL) != -1)
chroot.c:  while ((c = getopt_long (argc, argv, "+", long_opts, NULL)) != -1)
cksum.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
dd.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
dirname.c:  if (getopt_long (argc, argv, "+", NULL, NULL) != -1)
hostid.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
hostname.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
link.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
logname.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
nice.c:          optc = getopt_long (fake_argc, fake_argv, "+n:", longopts, 
NULL);
nohup.c:  if (getopt_long (argc, argv, "+", NULL, NULL) != -1)
setuidgid.c:    while ((c = getopt_long (argc, argv, "+g:", NULL, NULL)) != -1)
sleep.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
sync.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
timeout.c:  while ((c = getopt_long (argc, argv, "+k:s:", long_options, NULL)) 
!= -1)
tsort.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
unlink.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
uptime.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
users.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
whoami.c:  if (getopt_long (argc, argv, "", NULL, NULL) != -1)
yes.c:  if (getopt_long (argc, argv, "+", NULL, NULL) != -1)

That suggests that chroot and timeout at least should be
modified as you suggest.  I still think I'm missing something though?

cheers,
Pádraig.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]