Debian bug report logs - #911
libc causes rsh to fail on commands with option arguments

Message received at debian-bugs:

From cus.cam.ac.uk!iwj10 Thu May 25 04:10:49 1995
Return-Path: <iwj10@cus.cam.ac.uk>
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: <m0sEQex-0000XRZ.ijackson@nyx.cs.du.edu>
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.