On Mon, 9 Oct 2023 10:35:20 -0400 Chet Ramey <chet.ra...@case.edu> wrote:
> On 10/8/23 7:16 PM, Martin Schulte wrote: > > > The following has been tested with bash 5.2.15: > > > > - 3.7.5 Exit Status says: "All builtins return an exit status of 2 to > > indicate incorrect usage, generally invalid options or missing arguments." > > but cd with two or more non-optional arguments returns an exit status of 1. > > There is surprising variance in behavior here, from a status of 2 to 1 > to 0 (dash), plus the silly ksh "substitute old for new in $PWD," which > the NetBSD sh (!) also performs. I agree that a status of 2 is reasonable. > > The historical sh behavior is to ignore additional arguments. > > > - The same is true if exit is called with two or more argument where the > > first is numeric. This exit doesn't terminate bash. > > More varying behavior. ash-based shells (dash, BSD sh, etc.) ignore any > additional arguments -- the historical sh behavior. bash and yash treat > it as a non-fatal error. mksh treats it as a fatal error, which I suppose > it can because `exit' is a posix special builtin. Posix makes it all > explicitly unspecified, even whether the return status is non-zero. > > > - When exit is invoked with a non-numeric first argument it terminates > > bash. That seems to be inconsistent with the behaviour described before, > > while the exit status of the shell is 2 and consistent in some way. > > Everyone does this (including the exit status of 2) except ksh93, which > simply ignores any error and exits with a 0 status. Posix makes the > behavior unspecfied. Although, not everyone does it in the case that the shell is interactive. There is scarcely any opportunity to read the ensuing diagnostic message before the terminal potentially closes. Here is how it looks in Apple's Terminal, which defaults to "Don't close the window". $ exit foo logout -bash: exit: foo: numeric argument required Saving session... ...copying shared history... ...saving history...truncating history files... ...completed. That is, bash chooses to treat it as an error (which is perfectly sensible) but exits the interactive instance as a consequence. I think that the latter behaviour goes against the spirit of section 2.8.1 and that it is neither helpful nor useful. Instead, I think that it should continue to print the diagnostic message and set $? to 2, but not exit the interactive instance. -- Kerin Millar
