Re: Installing bash with rpath
On 1/22/19 2:25 PM, Chet Ramey wrot The bash link step doesn't do anything with rpath. The readline Makefiles set rpath to the installed location of the library at build time (using $libdir), so if you install it somewhere else that's going to be wrong. It should probably use $(DESTDIR)$(libdir) if that's what you use to install your copy of readline. Indeed, I don't modify the installation directory of readline and rpath works fine there. Is there any special reason that rpath isn't managed for Bash (similar to how its managed for readline)? Let me give some background on the cause of my problem and why I need to have rpath in Bash. I am an astrophysicist and maintainer of GNU Astronomy Utilities. In the sciences, we have a big problem of reproducibility: were research teams arrive at a result and publish it, but many don't know the versions of the programs they were using to get that result or how they were configured. As a result, many published research results are not reproducible. I am trying to tackle this problem in a "reproducible paper" project [1]. It builds all the necessary programs for a project (starting from Make and Bash and going all the way up to the higher-level science software used in a project and also an installation of TeX to enable creation of the paper in a closed environment also). It then runs those programs in the pre-defined order to get the exact same result, and finally builds the paper's PDF, using its internal build of LaTeX. Ofcourse, since many users use Mac, it has to also work on a Mac OS, so I don't currently build the C compiler or linker and rely on the host's low-level system libraries, compiler and linker. But above that, I try to keep everything. With the update of Bash and Readline 5.0 on my host operating system, I suddenly noticed that my build of Bash was crashing and after investigation I saw that it was actually linking to the readline installation on the host at run time, not to the readline within the project. I am currently using patchelf to add RPATH manually to the Bash executable. So I am really curious why RPATH isn't managed in Bash similar to how its managed in readline? Thanks a lot for all the great work on Bash and help and support, Cheers, Mohammad [1]: https://gitlab.com/makhlaghi/reproducible-paper/blob/pipeline/README-pipeline.md
Re: Installing bash with rpath
On 1/23/19 8:39 AM, Mohammad Akhlaghi wrote: > On 1/22/19 2:25 PM, Chet Ramey wrot >> The bash link step doesn't do anything with rpath. >> >> The readline Makefiles set rpath to the installed location of the library >> at build time (using $libdir), so if you install it somewhere else that's >> going to be wrong. It should probably use $(DESTDIR)$(libdir) if that's >> what you use to install your copy of readline. > > Indeed, I don't modify the installation directory of readline and rpath > works fine there. > > Is there any special reason that rpath isn't managed for Bash (similar to > how its managed for readline)? Because bash, by default, links statically with its own copy of readline. If you want to do things differently, there is a mechanism: specify the --rpath option to the linker. I don't know why that's not working for you. -- ``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: Readline bug?
On 1/23/19 5:49 AM, Greg Bell wrote: > Thanks for the quick help guys, much appreciated. Weird/annoying problem, > but at least it's known, and the workaround's fine. That behavior has been there in this form for around 25 years. -- ``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: Installing bash with rpath
On 1/23/19 2:13 PM, Chet Ramey wrote: Is there any special reason that rpath isn't managed for Bash (similar to how its managed for readline)? Because bash, by default, links statically with its own copy of readline. If you want to do things differently, there is a mechanism: specify the --rpath option to the linker. I don't know why that's not working for you. It is indeed very strange, because I am using the same script to build both bash and readline, but rpath is written in one and ignored in the other. I'll look for a solution in my scripts then. Thanks a lot for the prompt help, Mohammad
Re: UUID as Array Keys strangely not possible
On 1/22/19 3:32 PM, Robert White wrote:
> Howdy,
>
> The following cannot work because, for some reason, the array subscript
> parser insists on doing math on array indices even when the array is
> associative instead of numeric
>
> typeset -A UUID_TABLE
> ...
> UUID_TABLE+=( [${SOME_UUID}]=${SOME_VALUE} )
> ...
> some_command ${UUID_TABLE[${SOME_UUID}]}
>
> The parser and evaluator insist on doing math on ${SOME_UUID} no matter how
> its quoted or whatever. This seems extremely wrong.
I can't reproduce this. Given this script:
$ cat ./x18
typeset -A UUID_TABLE
while read SOME_UUID;
do
SOME_VALUE=42
UUID_TABLE+=( [${SOME_UUID}]=${SOME_VALUE} )
echo \${\UUID_TABLE\[${SOME_UUID}]} '<-' ${UUID_TABLE[${SOME_UUID}]}
done < ./x18.in
for f in ${!UUID_TABLE[@]}
do
printf "<%s> <%s>\n" "$f" "${UUID_TABLE[$f]}"
done
where the input file contains a list of UUIDs, one per line, I don't
see any arithmetic evaluation taking place. In fact, the expression
evaluator is never called.
--
``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/
RETURN trap will inherit last RETURN trap cmd though set +T
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong -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
-Wno-parentheses -Wno-format-security
uname output: Linux arch.ishbguy.org 4.20.3-arch1-1-ARCH #1 SMP PREEMPT Wed Jan
16 22:38:58 UTC 2019 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 0
Release Status: release
Description:
RETURN trap will inherit last RETURN trap cmd though set +T under bash 5.0 or
bash 4.4, however, this will not happen under bash 4.3. For example:
```
set +T
one { trap 'echo in one' RETURN; }
all {
trap 'echo in all' RETURN
one
}
all
```
in bash 5.0 and 4.4 will print:
```
in one
in one
```
in bash 4.3 will print:
```
in one
in all
```
Repeat-By:
Run this script:
```
set +T
one { trap 'echo in one' RETURN; }
all {
trap 'echo in all' RETURN
one
}
all
```
--
--
Herbert Shen
Mail: ishb...@hotmail.com
GitHub: https://github.com/ishbguy
--
Re: RETURN trap will inherit last RETURN trap cmd though set +T
On Wed, Jan 23, 2019 at 03:59:12PM +, Shen Herbert wrote:
(...)
> Repeat-By:
> Run this script:
> ```
> set +T
> one { trap 'echo in one' RETURN; }
> all {
> trap 'echo in all' RETURN
> one
> }
> all
> ```
Hm, the script above is a bit odd, these aren't syntactically valid function
definitions:
dualbus@system76-pc:~$ cat > file
set +T
one { trap 'echo in one' RETURN; }
all {
trap 'echo in all' RETURN
one
}
all
dualbus@system76-pc:~$ bash file
file: line 2: syntax error near unexpected token `}'
file: line 2: `one { trap 'echo in one' RETURN; }'
Do you have another example we can use?
Re: RETURN trap will inherit last RETURN trap cmd though set +T
On 1/23/19 10:59 AM, Shen Herbert wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe
> -fstack-protector-strong -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
> -Wno-parentheses -Wno-format-security
> uname output: Linux arch.ishbguy.org 4.20.3-arch1-1-ARCH #1 SMP PREEMPT Wed
> Jan 16 22:38:58 UTC 2019 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.0
> Patch Level: 0
> Release Status: release
>
> Description:
>
> RETURN trap will inherit last RETURN trap cmd though set +T under bash 5.0 or
> bash 4.4, however, this will not happen under bash 4.3. For example:
> ```
> set +T
> one { trap 'echo in one' RETURN; }
> all {
> trap 'echo in all' RETURN
> one
> }
> all
> ```
> in bash 5.0 and 4.4 will print:
> ```
> in one
> in one
> ```
> in bash 4.3 will print:
> ```
> in one
> in all
> ```
There is only a single RETURN trap; traps are not local. If a called
function sets the RETURN trap, it should overwrite the caller's trap,
and the caller's value should not get restored. Then, when the caller
returns, and there is a RETURN trap set, it should execute the current
RETURN trap, not the one it had before it called the second function
(`one' in this case).
The behavior of bash-4.3 was a bug. I changed it partly as the result of
this bug report:
http://lists.gnu.org/archive/html/bug-bash/2015-08/msg00130.html
This change made the behavior of the RETURN trap align with the DEBUG and
ERROR traps.
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/
