0

I want to create a bash alias setting that needs to place the first input argument in a specific location and then any/all the remaining ones on the end.

I can write it as so

alias dkritbsh "docker run --interactive --tty $1 /bin/bash $2 $3 $4 $5 $6 $7 $8 $9"

and having been testing and searching around for if its possible to author something like this

I can write it as so

alias dkritbsh "docker run --interactive --tty $1 /bin/bash $[2..9]"

as i can in powershell. i've tried using $(2..9) and $2..$9 as well with no luck.

Is this even doable in bash script alias settings?

myusrn
  • 1,050
  • 2
  • 15
  • 29
  • 2
    `dkritbsh() { local tty; tty=$1; shift; docker run --interactive --tty "$tty" /bin/bash "$@"; }` -- you have to use a function; `$1` etc in an alias do not refer to the arguments to the alias at all -- instead, they refer to the arguments to the shell or other context that the alias was run inside. It sometimes _looks_ like it works because the original argument list is appended to the result of an alias expansion, but looking like it works != actually working – Charles Duffy Oct 09 '21 at 18:07
  • Thanks that does the trick. Is there any significance for having double quotes around usage of the local variable assignment and the shifted remaining $@ arguments? I ask because i defined it without the quotes and it appears to produce the exact same result, e.g. `dkritbsh() { local image; image=$1; shift; docker run --interactive --tty $image /bin/bash $@; }` – myusrn Oct 11 '21 at 17:52
  • 1
    If you don't quote `$@` it acts exactly like `$*`. The differences don't show up if you use overly-trivial data, but they're very real. Similarly, `$tty` without quotes can expand into any number of shell words; `"$tty"` is guaranteed to expand to exactly one. In general, it's a bad idea to assume that things work in bash because they look like they work on a quick smoketest -- the language is full of corner cases and pitfalls, and if you don't know where the gotchas are you can't test for them. – Charles Duffy Oct 11 '21 at 18:16
  • 1
    [BashPitfalls](https://mywiki.wooledge.org/BashPitfalls) is a good place to start in getting used to the classes of common caveats. – Charles Duffy Oct 11 '21 at 18:18
  • 1
    To provide a concrete example, try `var='*'` and then compare `echo $var` and `echo "$var"`. Wildcards aren't the only messy case either, just the easiest to demonstrate (strings with spaces don't work right either, but `echo` can make them _look_ like they work; compare `var='two words'` and then `printf '%s\n' $var` and `printf '%s\n' "$var"`). – Charles Duffy Oct 11 '21 at 22:18
  • interesting so what seems like a processes variable value as a literal substitution and the other as string casted value. – myusrn Oct 13 '21 at 01:34
  • 1
    I'm not sure I understand your summation enough to say whether it's accurate or not. Even unquoted, parameter expansions go through different processing than shell syntax as such -- specifically, unquoted expansions are subject to string-splitting and glob expansion (but _only_ those steps, not other parsing processes), whereas quoted expansions skip both those steps and treat the variable's content literally. See [BashParser](https://mywiki.wooledge.org/BashParser) on the Wooledge wiki (which is a trustworthy resource in general). – Charles Duffy Oct 13 '21 at 01:38

0 Answers0