1

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 :

ADDITIONAL INFORMATION:

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
ilkkachu
  • 138,973
user1404316
  • 3,078
  • It looks like you're using screen for one but not the other. Are you? – Chris Davies 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
  • @glennjackman : not relevant, because when running the example as the same unprivileged user, but outside of tmux, the same error occurs. It's beginning to correlate to the value of TERM being either screen-256color or xterm-256color or whether it happens in or out of tmux. – user1404316 Mar 13 '18 at 14:51

1 Answers1

5

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

Solutions:

  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
glenn jackman
  • 85,964
  • 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 03: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 06: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 08:54