Ah, something was telling me that this could not have been missed, but
after checking behavior on couple of different shells (csh, ksh, tcsh) I
was convinced that it's not a proper behavior. Though now I see that, e.g.,
dash does the same thing. Note to myself: always check what POSIX has to
say. O
On 1/12/19 6:58 PM, Peng Yu wrote:
>> The bash-4.4 code only worked the way you want it by chance. There was a
> bug that was fixed in January, 2017, the result of
>
>> http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00018.html
>
>> that uncovered the behavior you're complaining about.
>
>
On 1/12/19 7:52 PM, mike b wrote:
> Upon changing directory, with "//" passed as an argument, the trailing '/'
> is still displayed when cwd is looked up by Bash:
>
> bash-5.0# cd //
> bash-5.0# pwd
> //
> bash-5.0# echo $PWD
> //
Bash FAQ, question E10. That should tell you how long this questio
Date:Sat, 12 Jan 2019 17:58:12 -0600
From:Peng Yu
Message-ID:
| I don't think it is a good idea to introduce such kind of special
| cases. If @() should match an empty string, the least surprising
| definition is that it should match empty string everywhere.
Date:Sun, 13 Jan 2019 01:52:03 +0100
From:mike b
Message-ID:
| This seems to happen only when number of '/' char == 2, anything > 2 is
| properly displayed as single '/' char.
That's because paths that start with exactly two '/' characters (not more,
not less)
Upon changing directory, with "//" passed as an argument, the trailing '/'
is still displayed when cwd is looked up by Bash:
bash-5.0# cd //
bash-5.0# pwd
//
bash-5.0# echo $PWD
//
bash-5.0# PS1=${PS1/\$/\w\\$}
bash-5.0//# # \w -> "//"
bash-5.0//# /bin/pwd # <- coreutils implementation
/
bash-5.0
> The bash-4.4 code only worked the way you want it by chance. There was a
bug that was fixed in January, 2017, the result of
> http://lists.gnu.org/archive/html/bug-bash/2017-01/msg00018.html
> that uncovered the behavior you're complaining about.
This only explains where the change of behavior
On 1/12/19 1:14 AM, kevin wrote:
>>> Moreover, the explanation in the Bash FAQ is unclear; it lacks examples to
>>> know when "an interference" occurred.
>> What is "an interference"?
>>
>>
>>> Look at the following answer to get an overview of the issue:
>>> https://stackoverflow.com/a/12696899
>
On 1/12/19 12:17 AM, Peng Yu wrote:
> See the following for the difference. I'd consider the behavior of
> 4.4.23 should be correct.
The bash-4.4 code only worked the way you want it by chance. There was a
bug that was fixed in January, 2017, the result of
http://lists.gnu.org/archive/html/bug-ba
