Why does/would the following printf statement behave differently based upon ...? (GNU bash, version 4.4.18(1)-release (x86_64-pc-linux-gnu))

printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/?}

When in an unprivileged user terminal session in tmux, the output is:

screen-256color : screen_256color : screen?256color

However, when in a root terminal, for the same tmux session the output is:

xterm-256color : xterm_256color :

Outside of tmux, the output is the same failure for all users:

xterm-256color : xterm_256color :


I just tried the same command line, but replacing the question mark with an asterisk, and the same failures and successes occur. Could it be an issue related somehow to globbing? The field is supposed to be treated as a string value, not a glob. Then I tried escaping the character and get the following results, for the six cases of asterisk plain, with one backslash, and with two backslashes, for xterm-256color and screen-256-color cases mentioned above:

printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/*}

screen-256color : screen_256color : screen*256color
xterm-256color : xterm_256color :

printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/\*}

screen-256color : screen_256color : screen*256color
xterm-256color : xterm_256color :

printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/\\*}

screen-256color : screen_256color : screen\*256color
xterm-256color : xterm_256color : xterm\*256color
  • It looks like you're using screen for one but not the other. Are you? – roaima Mar 13 '18 at 13:52
  • @roaima : No,although both examples were from a single tmux session (kind of like screen) on the same host. I just tried the example outside of tmux and it fails even for a regular account (with TERM=xterm-256color), so I need to update the question. Not sure exactly how to re-frame it yet ... – user1404316 Mar 13 '18 at 14:11
  • What is root's login shell? Is it bash? – glenn jackman Mar 13 '18 at 14:29
  • @glennjackman: yes, it is bash, same version. The version of tmux is debian package version 2.63 – user1404316 Mar 13 '18 at 14:35
  • You and root have different shell options. See below. – glenn jackman Mar 13 '18 at 14:37

I can reproduce:

$ printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/?}
xterm-256color : xterm_256color :

That's because no files match the pattern xterm?256color


  1. Quote your variables:

    $ printf "%s : %s : %s\n" "$TERM" "${TERM//[^[:alnum:]]/_}" "${TERM//[^[:alnum:]]/?}"
    xterm-256color : xterm_256color : xterm?256color
  2. Turn off filename expansion

    $ (set -f; printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/?})
    xterm-256color : xterm_256color : xterm?256color
  3. Turn off the nullglob shell option

    $ (shopt -u nullglob; printf "%s : %s : %s\n" $TERM  ${TERM//[^[:alnum:]]/_} ${TERM//[^[:alnum:]]/?})
    xterm-256color : xterm_256color : xterm?256color
  • That's it! and good link! Thanks. Although it doesn't seem to explain why the failure does NOT occur when within tmux. – user1404316 Mar 13 '18 at 14:55
  • Compare echo "$-" (set settings) and shopt between the 2 users/environments. – glenn jackman Mar 13 '18 at 16:48
  • You're correct. option nullglob was set differently. Not sure why, as all are using the same .bashrc, but that's a separate thing. – user1404316 Mar 14 '18 at 3:14
  • Quoting the variable expansions is the correct solution. Setting nullglob and turning off filename expansions just to avoid quoting variables is a bit of a hack. – Kusalananda Mar 14 '18 at 6:29
  • then there's also shopt -s failglob which would immediately complain instead of giving an odd result like in the question – ilkkachu Mar 14 '18 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.