> only current use for the (posix "is undefined") relative path in $ENV is
> if the intent is to run the script relative to whatever directory the
> shell happens to start in. I doubt that is often intended.
I would guess the most probable intent is to run it from $HOME (and wonder
why it some
Date:Thu, 13 Dec 2018 18:36:35 +0100
From:Edgar =?iso-8859-1?B?RnXf?=
Message-ID: <20181213173634.ge46...@trav.math.uni-bonn.de>
| > unless /etc/profile changes it, $HOME (for .profile)
| So, would it make sense to treat relative paths as relative to $HOME, then?
> unless /etc/profile changes it, $HOME (for .profile)
So, would it make sense to treat relative paths as relative to $HOME, then?
That way, you don't break existing setups where that was intended.
Date:Thu, 13 Dec 2018 09:39:44 +0100
From:Edgar =?iso-8859-1?B?RnXf?=
Message-ID: <20181213083944.gb46...@trav.math.uni-bonn.de>
| though. In the current version, what's a login-sh's wd at that time?
unless /etc/profile changes it, $HOME (for .profile) and unless
> I'm considering, if it seems reasonable to those here, to change sh so it does
> not read profile files (any of them) from relative paths (simply ignore any
> such attempt).
Yes, that sounds reasonable to me. I don't know how many people's profiles
it might break, though. In the current version
I have just committed the changes that allow parameter expansion on $ENV
before processing (as required by POSIX) - it will make no difference to most
people who have ENV set to a simple filename (if there are no $'s in the value
of ENV (and no backticks) then it is used just like before. We also
