Re: getcwd() returns with stale errno value upon error
On Thursday, June 26, 2025, Martin D Kealey wrote:
> There's a fairly obvious race condition where another process replaces a
> directory entry
That's not the case here.
between readlink and lstat.
Who said anything about them?
> I would like bash to cope more gracefully with "unexpected" results
Yeah? How far should it go? Should it check if a list is actually sorted
after calling qsort on it?
> PS: Under what circumstances would this occur on Linux, where «
> getcwd(buf,size) » is usually implemented as «
> readlink("/proc/self/cwd",buf,size) ».
>
I don't think it's realistic to expect bash to support every toy platform
with five or so users. But if you got time to waste on it, go ahead.
--
Oğuz
Re: getcwd() returns with stale errno value upon error
On 6/25/25 3:44 AM, Richard Weinberger wrote: Bash Version: 5.2 Patch Level: 37 Release Status: release Description: getcwd() as implemented in lib/sh/getcwd.c can return with NULL and a stale errno value if the algorithm fails. It aborts if readdir() returns NULL and no matching directory entry was found. But bash's getcwd() assumes that NULL from readdir() is always an error, which is not the case. This can happen on filesystems where d_ino != st_ino such as on Linux's OverlayFS. Thanks for the report. I'll look at this after bash-5.3 is released. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: getcwd() returns with stale errno value upon error
On Thu, 26 Jun 2025 at 04:07, Oğuz wrote:
> On Wednesday, June 25, 2025, Richard Weinberger
> wrote:
> >
> > This can happen on filesystems where d_ino != st_ino
>
> i.e. a broken filesystem.
Or not broken.
There's a fairly obvious race condition where another process replaces a
directory entry between readlink and lstat.
> What does any of this have to do with bash?
>
I would like bash to cope more gracefully with "unexpected" results; I
prefer not should to rush to judgement on whether something else is broken.
PS: Under what circumstances would this occur on Linux, where «
getcwd(buf,size) » is usually implemented as «
readlink("/proc/self/cwd",buf,size) ». (Usually this is *more* reliable,
since it works even when using readdir on "..", "../..", etc is blocked by
filesystem permissions.)
Re: variable replacement text differences
On 6/19/25 7:16 PM, Jeff Ketchum wrote:
I think that helps me understand the differences better, and what I am
seeing.
Though It doesn't seem like it is completely consistent, and not what I
expected when using a variable with specific layout. (and also breaking
change enabled by default)
example, if i change the replacement to '\a'
it stays as \a
$ bash replacestring.sh
original: 1|2|3|4 replace:\a
unqouted 1|\a|3|4
qouted 1|\a|3|4
so, it seems it only escapes it if its a double backslash, or escaping a &
and it is different again, if i change the script to do \a manually
$ cat replacestring.sh
original_string="1|2|3|4"
replace_string='\a'
echo "original: ${original_string} replace:${replace_string}"
echo "unqouted ${original_string/2/${replace_string}}"
echo "qouted ${original_string/2/"${replace_string}"}"
echo "manual ${original_string/2/\a}"
output for newer bash:
...
manual 1|a|3|4
This is the change between bash-4.2 and bash-4.3 that added quote removal.
this is slightly different behaviour from the variable, but in older
versions, it shows it
GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
$ bash /tmp/replacestring.sh
original: 1|2|3|4 replace:\a
unqouted 1|\a|3|4
qouted 1|"\a"|3|4
manual 1|\a|3|4
It could also be a double quote, '\"' that is escaped, and it doesn't
interpret the \ as an escape, which is a character that I would expect to
see that happen for.
Quote removal doesn't happen on the results of variable expansion -- an
expansion that contains a quote character doesn't have the quote character
removed.
also, a single \ doesn't have to be quoted either
replace_string='\'
Do you mean in the assignment statement? Backslash has no effect as an
escape character within single quotes.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Unexpected behavior of ${x#word} and ${x/pat/str} in the case command
On 6/23/25 5:02 AM, Takaaki Konno wrote:
Bash Version: 5.1
Patch Level: 4
Release Status: release
Description:
Parameters expanded to null by pattern removal or pattern substitution in the
patterns of case clauses produced unexpected results in some cases.
The version of bash in my system is 5.1, but the same results are produced in
bash 5.2.37 I built from source.
Repeat-By:
In the following example, I expected no output, but in fact it output "not
matched".
x=abc
case def in
"${x#abc}"def) ;;
"${x##abc}"def) ;;
"${x%abc}"def) ;;
"${x%%abc}"def) ;;
"${x/abc/}"def) ;;
"${x//abc/}"def) ;;
"${x/#abc/}"def) ;;
"${x/%abc/}"def) ;;
*) echo 'not matched'
esac
# => not matched
Thanks for the report. I'll fix this after bash-5.3 is released.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
