Open krader1961 opened 4 years ago
you ask why cd -
an cd ~-
produce "different failure modes".
answer: because these are two different commands. read the manpage....
NOTE: the error messages you report are not those reported by ksh93u+ (or of ksh2020, for that matter). what exactly is /bin/ksh in your test?
regarding cd -
the manpage says:
"If arg is -
the directory is changed to the previous directory. "
so this requires that there is a previous directory (which implies that OLDPWD is set). so the
"no OLDPWD" you see reflects this fact (but it should report "bad directory" if it is ksh93...). cd -
changes to OLDPWD or fails if the latter is unset. easy...
further you say "It seems to me that cd ~-
should be no-op if no prior cd
has been executed".
No, it should not. as all ksh-like shells agree (bash, mksh) to follow ksh93.
why do you not simply read the ksh manpage and look up tilde substitution (i.e. expansion)? you should make that a regular custom: read the manpage (multiple times, ideally) instead of jumping to random conclusions and speculation...
consider this (on OSX, say...):
ksh -c 'cd ~-' # → ksh: cd: ~-: [No such file or directory]
mkdir '~-'
ksh -c 'cd ~-; pwd' # executes the cd w/o error and exits
rmdir '~-' # provided you don't regularly have such a dir ...
this is exactly what should happen.
why? because ksh first does the tilde expansion in the specified way. this leads to no change of the string value ~-
since OLDPWD is NEVER yet in existence after a vanilla shell start. but as with other tilde expansions (say cd ~nonexistentusername
) if the tilde expansion fails the string is simply used unmodified in what follows.
so then ksh tries to cd
to the directory named verbatim ~-
. which might or might not exist (depending on how misguided the user is in his choices of dir names...). no problem at all.
bottom line: you are perceiving a non-existent problem/misbehaviour here. very obviously should cd ~-
NOT be a no-op if the tilde expansion does not succeed.
While removing problematic uses of
getconf LIBPATH
I noticed the src/cmd/ksh93/tests/exit.sh unit test contains these lines that I added almost two years ago to get thecd ~-
test at the end of that unit test to pass:https://github.com/att/ast/blob/2f06a34e737cb2a0d8c1a052d97924ad27e445e0/src/cmd/ksh93/tests/exit.sh#L32-L34
That workaround is needed on every platform other than macOS. This includes both the current version of ksh and ksh93u+. Which includes OpenIndiana (a Solaris clone), FreeBSD, OpenBSD, and several flavors of Linux. All you have to do is start a new shell and type
cd ~-
. On every platform other than macOS you get an error such as this (from ksh93u+ on OpenIndiana):This is because OLDPWD is not defined by a new shell on most platforms. For example, on OpenIndiana:
On MacOS:
Note that this behavior is true for both the last stable, ksh93u+, release and the current git master branch. This "just works" on macOS, but no other platform I have access to, because on macOS
OLDPWD
(at least for my shell environment) is exported and thus is imported by a newksh
instance. Presumably the old test framework implicitly did acd
in the context of the unit test prior to executing the body of the unit test. Thus making the finalcd ~-
"valid".Explain to me why these two commands produce different failure modes on every system I have access to other than macOS (where
OLDPWD
is exported):It seems to me that
cd ~-
should be no-op if no priorcd
has been executed.P.S., bash also exhibits the same behavior. If
OLDPWD
is in the environment when a bash shells starts it is usable bycd ~-
. If not you get a failure. And a google search suggests this is, more or less, expected behavior that is undefined by the POSIX shell specification. "More or less" because there seems to be some ambiguity regarding the "correct" behavior.