Bash parameter expansion – greedy versus non-greedy

bashvariable substitution

It's a bit of a contrived example but here goes:
Say I have a variable 1.2.3.4 containing version information and need to replace the .4 at the end with .5

version=1.2.3.4
echo ${version%.*}.5
1.2.3.5    #no problem

But when I attempt to "in-line" the substitution with / and a % anchor

echo ${version/%.*/.5}
1.5

Bash does a greedy substitution. Is there a way to have bash take the substitution up "non-greedily" so I can use substitution as a replacement for the earlier delete+append approach?

Best Answer

Not in general but easily in this case:

shopt -s extglob
echo ${version/%+([0-9])/}
1.2.3.

Related Solutions

Bash – Handling Duplicate Program Names

Your $PATH is searched sequentially. For example if echo $PATH shows /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin, each of those directories is searched in sequence for a given command (assuming the command isn't an alias or a shell builtin).

If you want to override specific binaries on a per-user basis (or you just don't have access to override for other users than yourself), I would recommend creating a bin directory in your home directory, and then prefixing your PATH variable with that directory.

Like so:

$ cd ~
$ pwd
/home/joe
$ mkdir bin
$ echo "$PATH"
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
$ echo 'export PATH="$HOME/bin:$PATH"' >> .bash_profile

Then source .bash_profile so the new PATH definition will take effect (or just log out and log in, or restart your terminal emulator).

$ source .bash_profile
$ echo "$PATH"
/home/joe/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

Now, any executable files you put in /home/joe/bin/ will take precedence over system binaries and executables.

Note that if you do have system access and the overrides should apply to all users, the preferred place to put override executables is /usr/local/bin, which is intended for this purpose. In fact often /usr/local/bin is already the first directory in $PATH specifically to allow this.

Bash – Parameter expansion for variable with leading white space

Field splitting occurs after expansion, and IFS whitespace is ignored at the beginning and end of the whole input (to avoid creating fields before the first "logical" field or after the last one). Thus by the time it gets to field splitting, your first example is

echo   one   two   'and three'

which is parsed into fields one, two, and and three; likewise your second example is

echo   one   two    'and three'

which is also parsed into fields one, two, and and three.

Best Answer

Related Solutions

Bash – Handling Duplicate Program Names

Bash – Parameter expansion for variable with leading white space

Related Question