Re: bug-bash Digest, Vol 218, Issue 13
On 1/10/21 6:00 PM, bug-bash-requ...@gnu.org wrote: Message: 3 Date: Sun, 10 Jan 2021 16:49:50 +0100 From: Ángel To: bug-bash@gnu.org Subject: Re: non-executable files in $PATH cause errors Message-ID: <94646752576f053515ac2ba4656fe0c895f348ce.ca...@16bits.net> Content-Type: text/plain; charset="ISO-8859-15" On 2021-01-10 at 08:52 +0100, n952162 wrote: Hello, I consider it a bug that bash (and its hash functionality) includes non-executable files in its execution look-up and then (inevitably) simply reports an error, because its such files aren't executable. Perhaps it's there to support PATH look up for arguments to the bash command. That would also be a bug. Why should it be okay to execute a non-executable script? Supporting users who are too lazy to chmod a file ought to be less important than supporting users who want fine-grain control over what's executable and what's not. Hello I can't reproduce what you report. $ mkdir foo bar $ printf '#!/bin/sh\necho Program "$0"\n' > foo/program $ printf '#!/bin/sh\necho Program "$0"\n' > bar/program $ PATH="$PATH:$PWD/foo:$PWD/bar" $ chmod +x bar/program $ program It is executing bar/program, not foo/program which is earlier in the path, but not executable. Maybe you just made the earlier program not executable, and the old path is still being remembered? You should run hash -r after making executable changes that will make an already-executed command find a different program in the path (in the example above, making foo/program executable, or removing again its +x bit). Best regards I unfortunately can't reproduce it, either, right now. I can't remember if I reconfigured something or was doing something special. When I encounter it again, I'll investigate it better. But here's a bug for you, in readline: - edit a line - go to some character - replace that character with another, using the "r" command. - cruise further down the line to another character - hit the "." repeat command The replace operation will not be executed, but rather the "x" operation. This has actually improved over the years. A while back, repeating an earlier operation like that would get characters tangled up. Now, it seems at least to be deterministic.
Re: 5.1 locale.c typos?
On Mon, Jan 11, 2021 at 08:07:58PM -0500, Henry Bent wrote: > locale.c: In function 'set_default_locale': > locale.c:94:3: error: 'local_shiftstates' undeclared (first use in this > function) >local_shiftstates = 0; >^ [...] > > These were supposed to be locale_shiftstates, no? Certainly looks that way. (For those reading and wondering why bash 5.1 built fine for them, the misspelled variables are in a different branch of an #if so they're only under some build configs, not others.)
Re: 5.1 locale.c typos?
On 1/11/21 8:07 PM, Henry Bent wrote: locale.c: In function 'set_default_locale': locale.c:94:3: error: 'local_shiftstates' undeclared (first use in this function) local_shiftstates = 0; Thanks for the report. I guess it just shows how rare non-multibyte systems are these days. 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/
Re: 5.1 locale.c typos?
On Tue, Jan 12, 2021, 08:58 Chet Ramey wrote: > On 1/11/21 8:07 PM, Henry Bent wrote: > > locale.c: In function 'set_default_locale': > > locale.c:94:3: error: 'local_shiftstates' undeclared (first use in this > > function) > > local_shiftstates = 0; > > Thanks for the report. I guess it just shows how rare non-multibyte systems > are these days. > > Chet > Well, I can report that I have a working bash 5.1 patch 4 on sparc-sun-solaris2.5.1, where this report is from, as well as Irix 4.0.5H and Tru64 V5.1B-6. None required anything other than trivial fixes. -Henry
Re: 5.1 locale.c typos?
On 1/12/21 9:09 AM, Henry Bent wrote: Well, I can report that I have a working bash 5.1 patch 4 on sparc-sun-solaris2.5.1, where this report is from, as well as Irix 4.0.5H and Tru64 V5.1B-6. None required anything other than trivial fixes. An archaeologist! -- ``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/
Memory leak in 5.1 when redeclaring arrays
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux Valhalla 5.9.14-arch1-1 #1 SMP PREEMPT Sat, 12 Dec 2020
14:37:12 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 4
Release Status: release
Description:
Redeclaring array variable leads to leaked memory in bash 5.1
It is required to define var as `declare -a FOO=(a b c)`
defining it simply as `FOO=(a b c)` does not introduce memory leak.
The same actions in bash 5.0 do not lead to memory leak.
Repeat-By:
Here is the script to reproduce the issue:
```
#!/bin/bash
SOURCE_FILE=/tmp/strings
echo 'declare -a STRINGS=(' > "$SOURCE_FILE"
for i in {1..100}; do
echo 'qwertyuiopasdfghjklzxcvbnm' >> "$SOURCE_FILE"
done
echo ')' >> "$SOURCE_FILE"
for i in {1..1}; do
if [ $((i%1000)) -eq 0 ]; then
printf '%d\t%s\n' "$((i/1000))" "$(grep VmRSS /proc/$$/status)"
fi
source "$SOURCE_FILE"
done
```
Sample output with bash 5.1:
1 VmRSS: 23276 kB
2 VmRSS: 41916 kB
3 VmRSS: 60688 kB
4 VmRSS: 79452 kB
5 VmRSS: 98088 kB
6 VmRSS:116988 kB
7 VmRSS:135628 kB
8 VmRSS:154528 kB
9 VmRSS:173296 kB
10 VmRSS:191932 kB
For comparison the same script under bash 5.0 does not leak:
$ bash-5.0/bash ~/test_bash_memleak.sh
1 VmRSS: 6124 kB
2 VmRSS: 6204 kB
3 VmRSS: 6204 kB
4 VmRSS: 6204 kB
5 VmRSS: 6204 kB
6 VmRSS: 6204 kB
7 VmRSS: 6204 kB
8 VmRSS: 6204 kB
9 VmRSS: 6204 kB
10 VmRSS: 6204 kB
Re: Memory leak in 5.1 when redeclaring arrays
On 1/12/21 5:51 AM, Alexander Mescheryakov wrote: Bash Version: 5.1 Patch Level: 4 Release Status: release Description: Redeclaring array variable leads to leaked memory in bash 5.1 It is required to define var as `declare -a FOO=(a b c)` defining it simply as `FOO=(a b c)` does not introduce memory leak. It's strange. The process RSS size definitely grows, but valgrind and other tools don't report any leaks. I'll have to look at it. 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/
Re: non-executable files in $PATH cause errors
On 2021/01/09 23:52, n952162 wrote: Hello, I consider it a bug that bash (and its hash functionality) includes non-executable files in its execution look-up But bash doesn't have an execution lookup. It has a PATH lookup, and a completion lookup (for executables when appropriate), but the closest thing to an execution lookup might be "type -a" to look for how a command is executed. In the completion lookup and in the execution lookup (type -a), it only lists executable files. and then (inevitably) simply reports an error, because its such files aren't executable. But it is not inevitable. Using 'cp' as an example. Assuming you have /usr/bin in your PATH, but ~/bin is in your PATH before /usr/bin, then try: "touch ~/bin/cp", then "hash -u" (to clear the hash lookup), then type "cp", you will find that it returns the value in /usr/bin, ignoring the non-executable file that was first in your PATH. So if an executable is in your PATH, it will return that in preference to a non-executable. Only when it can't find an executable does it return the non-executable. As for why this is useful? Perhaps someone just created a script script 'foo' in "~/bin", but forgot to toggle the execution bit. Then they know that they forgot to toggle the execution bit. So it only reports the non-executable when there is no other option -- not 'inevitably', which is useful because it reminds people they need to toggle the 'x' bit. Make sense?
