Let's say I have these variables defined in my bashrc:
i='cgi-bin/internal';
e='cgi-bin/external';
f='cgi-bin/foo';
b='cgi-bin/bar';
ad='cgi-bin/admin';
#etc...
When I use the variable on the command line vim $i/edit_TAB it will expand the variable and the input on the command line becomes vim /www/productX/subdomain_x/cgi-bin/internal/edit_ (respective to whatever site I'm on) and then I TABTAB to get the possible completions.
That's fine, the functionality isn't the problem. It's just that it can get annoying to see the full path every time rather than just the value of the variable.
Is there a way to not expand the bash variables on the command line without compromising functionality?
Is it the bash completion that's doing this?
The desired outcome would be $i not expanding to it's value (visually) or $i expanding to a relative path rather than the full path.
You might try using zsh instead of bash. In zsh,
vim $i[tab]
expands $i to a relative path
(Also Oh My Zsh is great for customizing zsh)
I am not sure which other settings you use in your bash startup scripts, but for me the following bash command does the trick:
complete -r -v
shopt -u direxpand
-u: Disable (unset) shell optional behavior flag
direxpand:
If set, Bash replaces directory names with the results of word expansion when performing filename completion. This changes the contents of the readline editing buffer. If not set, Bash attempts to preserve what the user typed.
Check current status with shopt direxpand (or all options with shopt).
Re-enable with shopt -s direxpand
Soure:
https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html
Using
shopt -u progcomp
worked for me, after this the tab did not expand variables anymore.
A shopt doc
https://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html
Related
I am trying to make a bash script that recognizes specific links from a text file, then sends a command that replaces a specific string in a different file with a image link.
This is what I have right now.
#!/bin/bash
alias https://www.examplelink.com='sed -i -e "/replacen_next_line/s/\".*\"/\"https://www.exampleimage.com\"/" to/image/replace.txt';
cd /to/link/file/example;
. ./filewithlink.txt;
I get this message whenever executed
./filewithlink.txt: https://www.examplelink.com: not found
The script works fine without links. So I assume special characters is the reason it isn't working. Not sure if this is necessary information but these are all the special characters used in the links :/._-?=
Deep in the dungeons of the bash manuals, there is the remark:
Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt (see the description of shopt under SHELL BUILTIN COMMANDS below).
Because you source the script, you might create a function instead of an alias.
Or, if that is not to your liking,
shopt -s expand_aliases
I'm currently working on a script that deletes all the PNG files from my Desktop. I want to create an array of file paths then use the rm command on each one.
This is the relevant bit of code:
#!/usr/bin/env bash
shopt -s nullglob
files=("$HOME"/Desktop/*.png)
files_found="${#files[#]}"
shopt -u nullglob
It has been recommend that I use shopt in case of no matching files.
However I'm on MacOS and just discovered that shopt is not available for ZSH. When I run the script I get command not found: shopt.
I've found the ZSH has an equivalent called setopt however after reading through the documentation I can't quite figure out which option is the correct one to use in the case. I can't seem to find any examples either.
Can anyone point me in the right direction?
The corresponding option in zsh is CSH_NULL_GLOB (documented in man zshoptions).b
setopt CSH_NULL_GLOB
(As far as I can tell, the idea of a pattern disappearing rather than being treated literally comes from csh.)
The more zsh-like approach is not to set this as a general option (as suggested in the answer given by chepner), but to decide on each pattern, whether or you want to have the nullglob effect. For example,
for f in x*y*(N)
do
echo $f
done
simply skips the loop if there are no files matching the pattern.
Just come to the realisation that the issue of shopt not being found was due to me auto-loading the file as a ZSH function.
The script worked perfectly when I ran it like so:
bash ./tidy-desktop
Previously I had been running it just with the command tidy-desktop
Instead I now have this in my zsh_aliases:
tidy-desktop="~/.zshfn/tidy-desktop"
Thanks to #Charles Duffy for helping me figure out what was going on there!
I have a script I'm trying to make at least somewhat platform-independent. Because I can't count on the PATHs or shell aliases of my users (some of whom have been known to create aliases matching "reserved words" meaningful to the shell), I've taken to aliasing all non-builtin shell commands with uppercase equivalents. This works fine when I do it semi-manually, e.g.
AWK=/usr/bin/awk
DATE=/bin/date
GREP=/bin/grep
, but not so well when I try it in a function by iterating through an array of commands:
createAliases() {
COMMANDS=(awk chmod date echo git mkdir)
WHICH=/usr/bin/which
for command in ${COMMANDS[#]}; do
${command^^}=$($WHICH ${command})
done
}
, which produces errors like AWK=/usr/bin/awk: No such file or directory. Is my attempt to use the string^^ up-casing mechanism interfering with the variable assignment? It looks like the shell is actually trying to run the (aliased) commands, which is not what I want.
Any assistance is appreciated!
The following seems to work:
shopt -s expand_aliases
createAliases() {
COMMANDS=(awk chmod date echo git mkdir)
WHICH=/usr/bin/which
for command in ${COMMANDS[#]}; do
alias ${command^^}=$($WHICH ${command})
done
}
Prefixing the assigment with alias actually registers the desired aliases.
The line shopt -s expand_aliases enables you to then use these alias from anywhere in the script, according to https://www.thegeekdiary.com/how-to-make-alias-command-work-in-bash-script-or-bashrc-file/
I wrote simple command that lets me run the last N commands from terminal history. It looks like this: $> r 3 which will replay the last 3 commands.
I have the following alias in my bash profile:
alias r="history -w; runlast $1"
And then the following simple perl script for the runlast command:
#!/usr/bin/env perl
use strict;
use warnings;
my $lines = $ARGV[0] || exit;
my #last_commands = split /\n/,
`bash -ic 'set -o history; history' | tail -$lines`;
#last_commands =
grep { $_ !~ /(^r |^history |^rm )/ }
map { local $_ = $_; s/^\s+\d+\s+//; $_ }
#last_commands;
foreach my $cmd (#last_commands) {
system("$cmd");
}
This works but my bash profile has aliases and other features (e.g. color output) I want the perl script to have access to. How do I load the bash profile for perl so it runs the bash commands with my bash profile? I read somewhere that if you "source the bash profile" for perl you can get it to work. So I tried adding source ~/.bash_profile; to my r command alias but that didn't have an effect. I'm not sure if I was doing that correctly, though.
The system forks a process in which it runs a shell, which is non-login and non-interactive; so no initialization is done and you get no aliases. Also note that the shell used is /bin/sh, which is generally a link to another shell. This is often bash but not always, so run bash explicitly.
To circumvent this you need to source the file with aliases, but as bash man page says
Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt (see the description of shopt under SHELL BUILTIN COMMANDS below).
Thus you need shopt -s expand_aliases, as mentioned. But there is another screw: on that same physical line aliases are not yet available; so it won't work like this in a one-liner.
I'd also recommend to put aliases in .bashrc, or in a separate file that is sourced.
Solutions
Add shopt -s expand_aliases to your ~/.bashrc, and before the aliases are defined (or the file with them sourced), and run bash as a login shell
system('/bin/bash', '-cl', 'source ~/.bashrc; command');
where -l is short for --login.
In my tests the source ~/.bashrc wasn't needed; however, the man page says
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
and goes on to specify that ~/.bashrc is read when an interactive shel that is not login runs. So I added explicit sourcing.
In my tests sourcing .bashrc (with shopt added) while not running as a login shell didn't work, and I am not sure why.
This is a little heavy-handed. Also, initialization may be undesirable to run from a script.
Source ~/.bashrc and issue shopt command, and then a newline before the command
system('/bin/bash', '-c',
'source ~/.bashrc; shopt -s expand_aliases\ncommand');
Really. It works.
Finally, is this necessary? It asks for trouble, and there is probably a better design.
Other comments
The backticks (qx) is context-aware. If it's used in list context – its return assigned to an array, for example – then the command's output is returned as a list of lines. When you use it as the argument for split then it is in the scalar context though, when all output is returned in one string. Just drop split
my #last_commands = `bash -ic 'set -o history; history $lines`;
where I also use history N to get last N lines. In this case the newlines stay.
history N returns last N lines of history so there is no need to pipe to last
Regex substitution in a map can be done without changing the original
map { s/^\s+\d+\s+//r } #last_commands;
With /r modifier the s/// operator returns the new string, not changing the original. This "non-destructive substitution" has been available since v5.14
No need to explicitly use $_ in the last grep, and no need for parenthesis in regex
grep { not /^r |^history |^rm ?/ } ...
or
grep { not /^(?:r|history|rm)[ ]?/ } ...
where parens are now needed, but as it is only for grouping the ?: makes it not capture the match. I use [ ] to emphasize that that space is intended; this is not necessary.
I also added ? to make space optional since history (and r?) may have no space.
The proper solution is to have your Perl script just print the commands, and make your current interactive shell eval the string printed from your history. (I would probably get rid of Perl entirely but that's beside the point here.)
If the commands get evaluated in the current shell, you avoid many contextual problems which would be very hard or even intractable with system() or generally anything involving a new process. For example, a subprocess cannot have access to non-exported variables in the current shell. var="foo", echo "$var"; r 1 is going to be very hard to solve correctly with your current approach. Using the current interactive shell will also naturally and easily solve the problems you were having with trying to get a noninteractive subshell act like an interactive one.
Aliases suck anyway, so let's redefine r as a function:
r(){
history -w
eval $(printlast "$1")
}
... where refactoring runlast into a different script printlast is a trivial additional requirement. Or maybe just turn it into a (much simpler!) shell function:
printlast () {
history "$1" |
perl -ne 's/^\s*\d+\s+\*?//; print unless m/^(history|rm?)($|\s)'
}
With this, you can also get rid of history -w from the r definition.
Notice how we are using Perl where it is useful; but the main functionality makes sense to keep in the shell when you're dealing with the shell.
You can't source in a Bash script into a Perl script. The bash_profile has to be sourced in by the shell that executes the command. When Perl runs system, it forks a new shell each time.
You have to source in the bash_profile for each command that you run through system:
system('source ~/.bash_profile; ' + $cmd);
One more thing, system invokes a non-interactive shell. So, your Bash aliases defined in .bash_profile won't work unless you invoke:
shopt -s expand_aliases
inside that script
I just encountered the following error with zsh when trying to use logcat.
Namely, when typing:
adb logcat *:D
I get the following error in zsh
zsh: no matches found: *:D
I have to escape the * like :
adb logcat \*:D
While using bash, I do not get the following error.
Why would it be like this?
zsh warns you by default if you use a glob with no matches. Bash, on the other hand, passes the unexpanded glob to the app, which is a potential problem if you don't know for certain what will match (or if you make a mistake). You can tell zsh to pass the unevaluated argument like bash with setopt nonomatch:
NOMATCH (+3) <C> <Z>
If a pattern for filename generation has no matches, print an
error, instead of leaving it unchanged in the argument list.
This also applies to file expansion of an initial `~' or `='.
Or drop the argument instead with setopt NULL_GLOB:
NULL_GLOB (-G)
If a pattern for filename generation has no matches, delete the
pattern from the argument list instead of reporting an error.
Overrides NOMATCH.
Bash actually has the same option (setopt nullglob), and can emulate zsh with setopt failglob
bash does try to expand it - it's just that when it fails to match anything, it lets the * through to the program you're calling. zsh doesn't (at least by default).
You can make bash act like zsh by setting the failglob option. Conversely, you can make zsh work like the bash default by turning off the NOMATCH option.
In terms of adb, no need to escape with backslashes. You can try
adb logcat '*:I'
Or an environment variable
export ANDROID_LOG_TAGS="*:I"
adb logcat
Short answer is: disable this by setopt nonomatch
(You can put it to ~/.zshrc) For more options, see #Kevin's answer.