Strange behavior of MSYS shell version 5.1.8 - shell

I have a strange behavior when the executing a program in a MSYS shell version 5.1.8. I'm on Windows 10 Version 22H2 (OS Build 19045.2251). The strange behavior occurs when a path is on a drive created with subst.
The following steps can be used to reproduce the behavior.
Inside a Windows CMD
C:\Users\f.redeker>subst s: "C:\Program Files\Common Files\System"
C:\Users\f.redeker>subst
S:\: => C:\Program Files\Common Files\System
Inside a shell version 5.1.8
sh-5.1$ uname -a
MSYS_NT-10.0-18362 MIMIR-W10-64 3.2.0-340.x86_64 2021-07-02 08:36 UTC x86_64 Msys
sh-5.1$ sh --version
GNU bash, version 5.1.8(1)-release (x86_64-pc-msys)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
sh-5.1$ realpath /s/ado/msadox.dll
/s/ado/msadox.dll
sh-5.1$ cd /s
sh-5.1$ pwd
/s
sh-5.1$ realpath ado/msadox.dll
/s/ado/msadox.dll
sh-5.1$ cd ado
sh-5.1$ pwd
/s/ado
sh-5.1$ realpath msadox.dll
/c/Program Files/Common Files/System/ado/msadox.dll
But
sh-5.1$ realpath /s/ado/sadox.dll
/s/ado/msadox.dll
Inside a shell version 4.4.19
sh-4.4$ uname -a
MSYS_NT-10.0-18362 MIMIR-W10-64 3.2.0-340.x86_64 2021-07-02 08:36 UTC x86_64 Msys
sh-4.4$ sh --version
GNU bash, version 4.4.19(2)-release (i686-pc-msys)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
sh-4.4$ cd /s
sh-4.4$ pwd
/s
sh-4.4$ realpath ado/msadox.dll
/s/ado/msadox.dll
sh-4.4$ cd ado
sh-4.4$ pwd
/s/ado
sh-4.4$ realpath msadox.dll
/s/ado/msadox.dll
With Process Monitor I have observed that the shell does not directly start the program to be executed, but first another shell. When creating this shell it seems that the current directory is given when CreateProcess is called.
Here, however, not the path with the subst drive is used but the one to which the subst drive points. Due to this behavior the Windows functions (e.g. _fullpath or GetFullPathName) do not return the result with the subst path if not an absolute path is specified as input parameter.
Is there any way to preserve the old behavior in current MSYS version?

Related

crashed "Ctrl-g" at "emacs -nw "

% uname -a
Linux xxxxxxx 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
% emacs --version
GNU Emacs 26.3
Copyright (C) 2019 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
% gnome-terminal --version
# GNOME Terminal 3.36.1.1 using VTE 0.60.3 +BIDI +GNUTLS +ICU +SYSTEMD
% emacs -nw test.c
when editing..
stroke "Ctrl-g"
crashed and display prompt
%
why??
Try emacs -nw -Q test.c.
That is, try Emacs without your init file: emacs -Q.
Then bisect your init file to find the culprit.

BASH_VERSINFO differs from what bash --version shows

I tried copying from /usr/local/Cellar/bash/4.4.19/bin/bash to /usr/local/bin/bash because which bash shows /usr/local/bin/bash.
~/cat /etc/shells
/usr/local/Cellar/bash/4.4.19/bin/bash
~/bash --version
GNU bash, version 4.4.19(1)-release (x86_64-apple-darwin17.3.0)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
echo $BASH_VERSINFO
3
How do I fix this?
bash --version shows the version that would be run if a new shell were started from the PATH.
Thus, this version correlates with the install location from which bash (if not modified by aliases/functions/etc), or type bash (more accurately), or with the shell used to run a script with a #!/usr/bin/env bash shebang.
$BASH_VERSINFO and $BASH_VERSION show the version that's running right now.
Thus, if you're in a script with a #!/bin/bash shebang, or an interactive shell script for a user whose password database specifies /bin/bash as their shell, /usr/local/bin/bash (or any other location) being earlier in the PATH is irrelevant for purposes of the current, not-started-from-the-PATH shell instance.
To start the shell from the PATH in a script, change your shebang to #!/usr/bin/env bash. To start a specified shell from an interactive session, use chsh to update your account's settings.

bash --version. Where this info are stored?

In which file are stored the info about the command
bash --version
?
I've tried in some directories like /bin or /var, /etc, but without results...
I need both for Linux and MAC OS x. Thanks!
Do you have any reason to believe that it is not hard-coded in the bash-executable itself?
To find out which bash is used, run
which bash
For me, it gives /bin/bash. Now, to see whether the executable has any string-like byte sequences in it that contain the substring "version", run
strings /bin/bash | grep version
On this machine, it gives:
shell_version_string
build_version
sccs_version
rl_library_version
rl_do_lowercase_version
show_shell_version
rl_readline_version
dist_version
GNU bash, version %s-(%s)
GNU bash, version %s (%s)
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
#(#)Bash version 4.3.48(1) release GNU
display-shell-version
-l do not print tilde-prefixed versions of directories relative
HOSTTYPE The type of CPU this version of Bash is running under.
OSTYPE The version of Unix this version of Bash is running on.
version, type `enable -n test'.
do-lowercase-version
.gnu.version
.gnu.version_r
Thus, "Bash version 4.3.48" is hard-coded in the executable as an ordinary string.
strings $(which bash) | grep "Bash version"
Output (e.g.):
#(#)Bash version 4.3.48(1) release GNU

How can I debug the Bourne Shell with gdb?

I built a toolchain script to prepare a Linux build environment. The script can be found here: https://github.com/mynameismevin/prometheus/blob/toolchain/ptool-make.sh
The script runs perfectly until after the Perl section around line 416. After Perl is done, when it goes to unzip sed, it complains with this error:
tar (child): sed-4.2.2.tar.bz2: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
However, if I run the sections by hand, it completes without errors. If I split the script into ptool-make1.sh (which ends at Perl) and ptool-make2.sh (which starts at sed) and run them sequentially then they both complete without any issues at all. At this point, I assert the issue isn't with the script, and I would like to debug the shell to see if it's an issue with the shell.
Here are some useful configurations:
user#ubuntu:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS"
user#ubuntu:~$ bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
user#ubuntu:~$ ls -lh $(which bash)
-rwxr-xr-x 1 root root 998K Oct 7 2014 /bin/bash
I don't think Ubuntu bash comes with debugging symbols, so I would assume I would have to recompile to include those?
How would I use gdb to debug the shell when I run a script? Or how would I have the shell log to a file while the script runs so I can open it with gdb after it's done? I know how to debug a shell script, I don't want to debug the script, I want to debug the shell.
Edit: It doesn't look like Ubuntu bash comes with debugging symbols out of the box. Reading symbols from bash...(no debugging symbols found)...done.
Edit: $PROMETHEUS is set in my root shell. At the end of Perl cd .. results in the same results a cd $PROMETHEUS/sources/.
Shells come with their own debugging tools. The most simple is running them with -x (bash -x ...script...) which will print each command after variable expansion but before it is executed. That's usually enough to determine the problem.
For more ideas, see How to debug a bash script?
You should also consider to write helper functions to reduce the size of the script to just a few lines. You could move special options to configure or post-build steps into extra files and run them from the helper function if they exist.
Looking at the code, it seems that this line is the culrit:
cd $PROMETHEUS/sources/
everywhere else, you just use cd ... If PROMETHEUS isn't defined (the script doesn't define it, that becomes cd /sources/ which should also fail but doesn't abort your script. Try
cd $PROMETHEUS/sources/ || exit 1
instead. Also #!/bin/bash -u might be useful (abort on undefined variables).
Lastly, you can use pushd and popd to navigate the folders.

Setting PATH variable from inside makefile does not work for make 3.81

Change the environment variable `PATH' in Makefile does NOT take effect with make in CLT, and it's OK with the make util which I compiled from original source.
The simple Makefile
PATH := $(PATH):/opt/bin
export PATH
all:
#cscope --version
My tests
/tmp $ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin
/tmp $ ls /opt/bin/cscope
/opt/bin/cscope
/tmp $ which make
/usr/bin/make
/tmp $ make
make: cscope: No such file or directory
make: *** [all] Error 1
/tmp $ ./_install/bin/make
cscope: version 15.7a
/tmp $ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
/tmp $ ./_install/bin/make --version
GNU Make 3.82
Built for x86_64-apple-darwin12.0.0
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Can anyone help?
You are confusing make variables with shell variables. With your setup, the shell command that gets invoked is not influenced by the make variable PATH that you have set.
You should set the PATH variable inside your recipe, like in
all:
#PATH=$(PATH):/opt/bin; cscope --version
You have to to both on one line because every line in the recipe will be run in another shell, effectively losing the PATH setting that you just did. Or you can divide it over multiple lines by adding a backslash \ at the end of each line:
all:
#PATH=$(PATH):/opt/bin; \
cscope --version
Update
Sorry, I missed the importance of your makefile working with make 3.82. I tried with both versions and indeed, 3.81 and 3.82 behave differently in this case.
I did get this to work with 3.81 though by invoking make as follows:
make SHELL="/bin/sh -c"
or
make SHELL=/bin/bash

Resources