Debian bug report logs - #911 libc causes rsh to fail on commands with option arguments Package: libc ; Reported by: iwj10@cus.cam.ac.uk (Ian Jackson); 159 days old . ----------------------------------------------------------------------- Message received at debian-bugs: From cus.cam.ac.uk!iwj10 Thu May 25 04:10:49 1995 Return-Path: Received: from pixar.com by mongo.pixar.com with smtp (Smail3.1.28.1 #15) id m0sEaoT-00060BC; Thu, 25 May 95 04:10 PDT Received: from bootes.cus.cam.ac.uk by pixar.com with SMTP id AA13075 (5.67b/IDA-1.5 for debian-bugs-pipe@mongo.pixar.com); Thu, 25 May 1995 04:09:19 -0700 Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #36) id m0sEaoI-000C0GC; Thu, 25 May 95 12:10 BST Received: by chiark id m0sEQex-0000XRZ (Debian /\oo/\ Smail3.1.29.1 #29.31); Thu, 25 May 95 01:20 BST Message-Id: Date: Thu, 25 May 95 01:20 BST From: iwj10@cus.cam.ac.uk (Ian Jackson) To: debian-bugs@pixar.com Subject: libc causes rsh to fail on commands with option arguments Package: libc Version: 4.6.27-5 Steve Greenland writes: > [Peter Tobias writes:] > > As far as I can see there is nothing wrong with the getopt stuff in rsh. > > I think the best way to fix it would be to add a working version of (a bsd) > > getopt to libbsd. The advantage of this way would be that all bsd programs > > would use the same handling of options (the normal 'bsd style'). > > > > What do you (and the members of debian-devel) think? > > The disadvantage is that you would have two groups of programs that > handle options in (possibly subtly) different ways. Some of you > may be able to instinctively distinguish between the two groups, > but I suspect that most Linux users won't. They'll just be confused. I agree. If this is a bug in the libc then it should be fixed for all programs, not just for rsh. (I'm reporting this as a bug in the libc now.) I read in libc.info, node `Argument Syntax': The implementation of `getopt' in the GNU C library normally makes it appear as if all the option arguments were specified before all the non-option arguments for the purposes of parsing, even if the user of your program intermixed option and non-option arguments. It does this by reordering the elements of the ARGV array. This behavior is nonstandard; if you want to suppress it, define the `_POSIX_OPTION_ORDER' environment variable. *Note Standard Environment::. (Note that this *may* not describe the way things are done in Linux, of course.) I suggest that things be arranged so that this behaviour is turned off by default, and that those applications that need it be given a way to turn it on if they need it. I notice that `ls' has this behaviour too, for example. This can defeat many things, including one of most portable ways of getting non-options that look like options to a program: namely, preceding them with a non-option argument. Furthermore, it will encourage people to write non-portable shell scripts and generally to become used to this odd behaviour. Having every user define _POSIX_OPTION_ORDER in their environment is not an option. (Note that an environment variable to set to get the nonstandard behaviour wouldn't work, because it would be inherited by shell scripts that might expect the standard behaviour.) Ian. ----------------------------------------------------------------------- Acknowledgement sent to iwj10@cus.cam.ac.uk (Ian Jackson) : New bug report received and forwarded. Full text available. ----------------------------------------------------------------------- Report forwarded to debian-devel@pixar.com : Bug#911 ; Package libc . Full text available. ----------------------------------------------------------------------- Ian Jackson / iwj10@thor.cam.ac.uk , with the debian-bugs tracking mechanism This page last modified 07:43:01 GMT Wed 01 Nov