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
Related
.inputrc commands vi-cmd-mode-string and vi-ins-mode-string are not working. No prefix is shown at the beginning of the bash prompt. But the input mode is indeed vim (I can switch between command / insert mode).
I'm on macOS Catalina 10.15.1. I've installed bash with brew install bash (also tested brew install --HEAD to compile locally).
My bash version is 5.0.11. Should be enough for vi-ins|cmd-mode-string that is available since bash 4.4 (https://stackoverflow.com/a/32614367/2058840)
bash --version
GNU bash, version 5.0.11(1)-release (x86_64-apple-darwin19.0.0)
Copyright (C) 2019 Free Software Foundation, Inc.
I've also install readline via brew, but this changes nothing.
My .inputrc :
$if Bash
set editing-mode vi
$endif
$if mode=vi
set show-mode-in-prompt on
set vi-cmd-mode-string bbbbb
set vi-ins-mode-string aaaaa
$endif
What am I missing here? With this bash version, I expect bbbb or aaaa to be shown as the bash prompt prefix.
Ok. Just found out it's not a problem with the homebrew bash version.
My macOS user config still use the default bash version /bin/bash (bash 3) instead of the homebrew one /usr/local/bin/bash.
You can change yours with https://www.howtogeek.com/444596/how-to-change-the-default-shell-to-bash-in-macos-catalina/.
It took me time to understand that because of the bash --version test. This test the version of the first bash accessible in your $PATH. Not the bash used to open your shell.
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.
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.
I have been trying to use GNU parallel for some time, but I have never been able to get it to function at all!
For example, running (in a non-empty directory!):
ls | parallel echo # Outputs single new line
ls | parallel echo echo echo # Outputs three new lines.
ls | parallel echo {} # /bin/bash: {}: command not found
ls | parallel echo '{}' # /bin/bash: {}: command not found
ls | parallel 'echo {}' # Outputs: {}
ls | parallel -IMM 'echo MM' # Outputs: MM
It seems that it is simply executing each argument as a command, which makes no sense.
I have tried bash, zsh, tcsh, csh, and sh, to no avail.
As I was about to complete writing this question, I ran parallel --version to report the version, only to find:
WARNING: YOU ARE USING --tollef. IF THINGS ARE ACTING WEIRD USE --gnu.
It is not clear to me why that flag is set by default. Needless to say, using --gnu worked!
Thought I would post this to save someone hours of frustration and confusion.
EDIT:
To fix this permanently (in Ubuntu at least), delete the --tollef flag in /etc/parallel/config
Depending on your operating system, you should check whether you're actually running the GNU version.
$ parallel --version
parallel: invalid option -- '-'
parallel [OPTIONS] command -- arguments
for each argument, run command with argument, in parallel
parallel [OPTIONS] -- commands
run specified commands in parallel
If this is the case, you're not running the GNU version. Ubuntu 12.04 is like this, and you'll need to manually install GNU parallel to get the functionality you expect.
Had issues running parallel as an external command from FREEMAT (MATLAB lookalike); the argumentFile was not fed to the command properly solved it by:
Adding --gnu to options
Not using cmdString syntax involving ["]
Code:
cmdString = 'parallel --gnu command ::: ';
while j<=jLength
cmdString = [cmdString argumentFilePath(j,:) ' '];
j=j+1;
end
system(cmdString)
Thank you for that :)
Im on Ubuntu 12.04 as well.
For me it was same issue but different problem. Just running parallel command was exiting silently. Also parallel --version was saying invalid option error. In my Path there was just one parallel executable binary but still it was not detecting.
I was able to fix it as below:
Run whereis parallel. This gives all the paths where executables named parallel is present. For my case there was just one path /usr/local/bin/parallel. Running using this path works just fine.
You can add an alias for this in ~/.bashrc or ~/.zshrc file like alias parallel='/usr/local/bin/parallel'
And now parallel works like charm.
dev-dsk % parallel --version
GNU parallel 20190322
Copyright (C) 2007-2019 Ole Tange and 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.
GNU parallel comes with no warranty.
While Googling for another bash tip, I found this page on .inputrc http://ss64.com/bash/syntax-inputrc.html, which exactly fixed what I was trying to do (put a trailing / on symlinks to directories), but as I read further, I saw that there was a way to skip completed text as well. "Awesome", I said to myself, "this bugs me about twice a week". So, I put that into my .inputrc as well, but it doesn't work, or even seem to recognize what's going on. After logging out, and logging back in, this is what I'm seeing:
$ tail .inputrc
set mark-symlinked-directories on
set skip-completed-text on
$ bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
Copyright (C) 2007 Free Software Foundation, Inc.
$ bind -V | grep completed
$ bind -V | grep skip
$
That is, bash doesn't seem to recognize it's there at all... Is there something wrong with the version of bash supplied in Mountain Lion? Anything blindingly obvious I've forgotten to do?
skip-completed-text is new to bash version 4.
The: skip-completed-text is only in bash4.
On my Mac:
$ bash --version
GNU bash, version 4.2.37(2)-release (i386-apple-darwin12.1.0)
If you want install some opensource utilities i recommending you using macports (www.macports.org). Installing macports will give you one command called port and with it you can install things dead simply, like:
$ port install bash
will install bash 4 for you.
Bash v4 won't make it to OSX. Might I suggest zsh, which is not GPL3.