Multiple output with bash command - bash

I want to find the 2 version of python. If I write:
{python2,python3}" --version; "
I am expecting it to run:
python2 --version; python3 --version;
and provide me the versions like if I would have written the above line directly :
Python 2.7.18
Python 3.8.10
but instead I get:
python2 --version;: command not found
even though if I test the output with:
echo {python2,python3}" --version"
I do get the expected:
python2 --version; python3 --version;
Trying
`echo {python2,python3}" --version"`
didn't work either.
Why? How do I make it work?

Because that's not what it does. You are creating two quoted strings "python2 --version; " and "python3 --version; " neither of which is a valid command. You could get around that with eval but ... that way lies madness.
# XXX DON'T
eval python{2,3}" --version;"
2.7.18
Python 3.8.10
The (not so) simple but straightforward solution would be something like
for v in 2 3; do
python$v --version
done
or if you are hellbent on using a wildcard, run a subshell:
echo python{2,3}" --version;" | bash
Perhaps notice the (lack of) difference between
echo python2" --version; "
and
echo "python2 --version; "
The quotes simply tell the shell to keep things together as a single string. (For what it's worth, the shell removes the quotes as part of its parsing process, so the argument to echo does not contain any actual quotes, just the parsed string from between the quotes.)
It's possible to have command names with literal spaces in them, but incredibly cumbersome; so you don't see this much in practice.
For fun, maybe try
# Have a directory in your PATH which is in your home directory
# If you don't, maybe create $HOME/bin and add it to your PATH
bash$ echo "$PATH" | tr ':' '\n' | grep "$HOME"
/users/you/bin
bash$ cat >"$HOME/bin/python2 --version"
#!/bin/sh
exec python2 --version
^D
bash$ chmod +x "$HOME/bin/python2 --version"
bash$ "python2 --version"
2.7.18
(Maybe delete the script when you're done experimenting.)

Related

'sh' environment does not respect the PATH extensions, user's local PATH not in effect?

$ bl 1
$ sh -c 'bl 1'
sh: bl: command not found
The bl script is located in the user's PATH extension (/home/user/.local/bin) but the sh environment does not seem to be aware of it, the bash is. The main /usr/bin/sh executable symlinks to /usr/bin/bash.
Placing a symlink in /usr/local/bin pointing to the local bl script does seem to fix the issue. Expanding the PATH manually $ PATH=/usr/bin:$HOME/.local/bin sh -c 'bl 1' also solves it, something I don't really understand since both the bash and the sh are aware of the PATH.
$ export -p |grep PATH=
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:~/.local/bin"
$ sh -c 'export -p |grep PATH'
export PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:~/.local/bin"
"Something's missing and you have to find it" yet it's hard to look if you don't know what is missing.
$ export -p |grep PATH
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:~/.local/bin"
Having a literal ~ is wrong. It should have been expanded to /home/user already. The shell will expand ~ when variables are assigned but not when they're expanded.
$ foo=~ && echo $foo # expanded at assignment
/home/user
$ foo='~' && echo $foo # not expanded since the assignment is quoted
~
Find the shell startup script where ~/.local/bin is added to the $PATH and make sure ~ is not quoted.
Wrong:
PATH="$PATH:~/.local/bin"
Right:
PATH=$PATH:~/.local/bin

No such file or directory in Heredoc, Bash

I am deeply confused by Bash's Heredoc construct behaviour.
Here is what I am doing:
#!/bin/bash
user="some_user"
server="some_server"
address="$user"#"$server"
printf -v user_q '%q' "$user"
function run {
ssh "$address" /bin/bash "$#"
}
run << SSHCONNECTION1
sudo dpkg-query -W -f='${Status}' nano 2>/dev/null | grep -c "ok installed" > /home/$user_q/check.txt
softwareInstalled=$(cat /home/$user_q/check.txt)
SSHCONNECTION1
What I get is
cat: /home/some_user/check.txt: No such file or directory
This is very bizarre, because the file exists if I was to connect using SSH and check the following path.
What am I doing wrong? File is not executable, just a text file.
Thank you.
If you want the cat to run remotely, rather than locally during the heredoc's evaluation, escape the $ in the $(...):
softwareInstalled=\$(cat /home/$user_q/check.txt)
Of course, this only has meaning if some other part of your remote script then refers to "$softwareInstalled" (or, since it's in an unquoted heredoc, "\$softwareInstalled").

How to "hide" an executable from a bash script?

I want to test the output of a bash script when one of the executables it depends on is missing, so I want to run that script with the dependency "hidden" but no others. PATH= ./script isn't an option because the script needs to run other executables before it reaches the statement I want to test. Is there a way of "hiding" an executable from a script without altering the filesystem?
For a concrete example, I want to run this script but hide the git executable (which is its main dependency) from it so that I can test its output under these conditions.
You can use the builtin command, hash:
hash [-r] [-p filename] [-dt] [name]
Each time hash is invoked, it remembers the full pathnames of the commands specified as name arguments, so they need not be searched for on subsequent invocations. ... The -p option inhibits the path search, and filename is used as the location of name. ... The -d option causes the shell to forget the remembered location of each name.
By passing a non-existent file to the -p option, it will be as if the command can't be found (although it can still be accessed by the full path). Passing -d undoes the effect.
$ hash -p /dev/null/git git
$ git --version
bash: /dev/null/git: command not found
$ /usr/bin/git --version
git version 1.9.5
$ hash -d git
$ git --version
git version 1.9.5
Add a function named git
git() { false; }
That will "hide" the git command
To copy #npostavs's idea, you can still get to the "real" git with the command builtin:
command git --version
Since we know the program is running in bash, one solution is to - instead of "hiding" the program - emulate the behaviour of bash in this circumstance. We can find out what bash does when a command isn't found quite easily:
$ bash
$ not-a-command > stdout 2> stderr
$ echo $?
127
$ cat stdout
$ cat stderr
bash: not-a-command: command not found
We can then write this behaviour to a script with the executable name, such as git in the question's example:
$ echo 'echo >&2 "bash: git: command not found" && exit 127' > git
$ chmod +x git
$ PATH="$PWD:$PATH" git
$ echo $?
127
$ cat stdout
$ cat stderr
bash: git: command not found

Echo command output "-n" in a file from Makefile

I have a Makefile that has this kind of command:
browserify:
rm -rf ./dist
mkdir dist
# Browserify
echo -n "/* ${NPM_PACKAGE} ${NPM_VERSION} ${GITHUB_PROJ} */" \
> dist/pica.js
So when I do make browserify it should output the comment to the top of the file without \n. But for some reasons... the output looks like this
-n /* package 0.0.0 */
...more things...
I'm using zsh on osx.
It doesn't matter what shell you are using. Make will always use /bin/sh as the shell it invokes (unless you specifically set the SHELL make variable to something else). Think what a disaster it would be if make used whatever shell the user was using to invoke recipes!
On many GNU/Linux systems, /bin/sh is actually a link to bash. On other GNU/Linux systems, /bin/sh is a link to dash which is a small, POSIX-standard shell without all the extensions bash uses (dash is good for running portable shell scripts fast, but not good for a user's interactive shell as it's missing too many expected features). On non-GNU-based systems (like OSX) /bin/sh might be ksh or something else even.
There is no portable, standard way to invoke echo in such a way that it doesn't print the trailing newline. There is an echo program, and different ones work differently. Many shells, including bash and zsh also have an echo built-in to the shell:
$ type -a echo
echo is a shell builtin
echo is /bin/echo
and these versions of echo also work differently than the program echo. Some versions have no way to suppress newlines. Some use the -n flag. Some use \c at the end to suppress printing the newline. Some support a combination of them.
The short answer is that if you want to print a line in the shell without a newline in a portable and reliable way, you should use the printf program to do it, not echo:
browserify:
rm -rf ./dist
mkdir dist
# Browserify
printf %s "/* ${NPM_PACKAGE} ${NPM_VERSION} ${GITHUB_PROJ} */" \
> dist/pica.js

How to find out where alias (in the bash sense) is defined when running Terminal in Mac OS X

How can I find out where an alias is defined on my system? I am referring to the kind of alias that is used within a Terminal session launched from Mac OS X (10.6.3).
For example, if I enter the alias command with no parameters at a Terminal command prompt, I get a list of aliases that I have set, for example:
alias mysql='/usr/local/mysql/bin/mysql'
However, I have searched all over my system using Spotlight and mdfind in various startup files and so far can not find where this alias has been defined. ( I did it a long time ago and didn't write down where I assigned the alias).
For OSX, this 2-step sequence worked well for me, in locating an alias I'd created long ago and couldn't locate in expected place (~/.zshrc).
cweekly:~ $ which la
la: aliased to ls -lAh
cweekly:~$ grep -r ' ls -lAh' ~
/Users/cweekly//.oh-my-zsh/lib/aliases.zsh:alias la='ls -lAh'
Aha! "Hiding" in ~/.oh-my-zsh/lib/aliases.zsh. I had poked around a bit in .oh-my-zsh but had overlooked lib/aliases.zsh.
you can just simply type in alias on the command prompt to see what aliases you have. Otherwise, you can do a find on the most common places where aliases are defined, eg
grep -RHi "alias" /etc /root
First use the following commands
List all functions
functions
List all aliases
alias
If you aren't finding the alias or function consider a more aggressive searching method
Bash version
bash -ixlc : 2>&1 | grep thingToSearchHere
Zsh version
zsh -ixc : 2>&1 | grep thingToSearchHere
Brief Explanation of Options
-i Force shell to be interactive.
-c Take the first argument as a command to execute
-x -- equivalent to --xtrace
-l Make bash act as if invoked as a login shell
Also in future these are the standard bash config files
/etc/profile
~/.bash_profile or ~/.bash_login or ~/.profile
~/.bash_logout
~/.bashrc
More info: http://www.heimhardt.com/htdocs/bashrcs.html
A bit late to the party, but I was having the same problem (trying to find where the "l." command was aliased in RHEL6), and ended up in a place not mentioned in the previous answers. It may not be found in all bash implementations, but if the /etc/profile.d/ directory exists, try grepping there for unexplained aliases. That's where I found:
[user#server ~]$ grep l\\. /etc/profile.d/*
/etc/profile.d/colorls.csh:alias l. 'ls -d .*'
/etc/profile.d/colorls.csh:alias l. 'ls -d .* --color=auto'
/etc/profile.d/colorls.sh: alias l.='ls -d .*' 2>/dev/null
/etc/profile.d/colorls.sh:alias l.='ls -d .* --color=auto' 2>/dev/null
The directory isn't mentioned in the bash manpage, and isn't properly part of where bash searches for profile/startup info, but in the case of RHEL you can see the calling code within /etc/profile:
for i in /etc/profile.d/*.sh ; do
if [ -r "$i" ]; then
if [ "${-#*i}" != "$-" ]; then
. "$i"
else
. "$i" >/dev/null 2>&1
fi
fi
done
Please do check custom installations/addons/plugins you have added, in addition to the .zshrc/.bashrc/.profile etc files
So for me: it was git aliased to 'g'.
$ which g
g: aliased to git
Then I ran the following command to list all aliases
$ alias
I found a whole lot of git related aliases that I knew I had not manually added.
This got me thinking about packages or configurations I had installed. And so went to the
.oh-my-zsh
directory. Here I ran the following command:
$ grep -r 'git' . |grep -i alias
And lo and behold, I found my alias in :
./plugins/git/git.plugin.zsh
I found the answer ( I had been staring at the correct file but missed the obvious ).
The aliases in my case are defined in the file ~/.bash_profile
Somehow this eluded me.
For more complex setups (e.g. when you're using a shell script framework like bash-it, oh-my-zsh or the likes) it's often useful to add 'alias mysql' at key positions in your scripts. This will help you figure out exactly when the alias is added.
e.g.:
echo "before sourcing .bash-it:"
alias mysql
. $HOME/.bash-it/bash-it.sh
echo "after sourcing bash:"
alias mysql
I think that maybe this is similar to what ghostdog74 meant however their command didn't work for me.
I would try something like this:
for i in `find . -type f`; do # find all files in/under current dir
echo "========"
echo $i # print file name
cat $i | grep "alias" # find if it has alias and if it does print the line containing it
done
If you wanted to be really fancy you could even add an if [[ grep -c "alias" ]] then <print file name>
The only reliable way of finding where the alias could have been defined is by analyzing the list of files opened by bash using dtruss.
If
$ csrutil status
System Integrity Protection status: enabled.
you won't be able to open bash and you may need a copy.
$ cp /bin/bash mybash
$ $ codesign --remove-signature mybash
and then use
sudo dtruss -t open ./mybash -ic exit 2>&1 | awk -F'"' '/^open/ {print substr($2, 0, length($2)-2)}'
to list all the files where the alias could have been defined, like
/dev/dtracehelper
/dev/tty
/usr/share/locale/en_CA.UTF-8/LC_MESSAGES/BASH.mo
/usr/share/locale/en_CA.utf8/LC_MESSAGES/BASH.mo
/usr/share/locale/en_CA/LC_MESSAGES/BASH.mo
/usr/share/locale/en.UTF-8/LC_MESSAGES/BASH.mo
/usr/share/locale/en.utf8/LC_MESSAGES/BASH.mo
/usr/share/locale/en/LC_MESSAGES/BASH.mo
/Users/user/.bashrc
/Users/user/.bash_aliases
/Users/user/.bash_history
...
Try: alias | grep name_of_alias
Ex.: alias | grep mysql
or, as already mentioned above
which name_of_alias
In my case, I use Oh My Zsh, so I put aliases definition in ~/.zshrc file.

Resources