Difference in bash printf output between run script and source script

I can't seem to find the difference between a script run two different ways.

Here's the script (named test.sh):

#! /bin/bash
printf "%b\n" "\u5A"

When the script is sourced:

. test.sh
> Z         ## Result I want ##

When the script is run:

./test.sh
> \u5A      ## Result I get ##

I want the run script to give the results of the sourced script... what setting do I need to set/change?

You are probably getting different versions of printf; the script you are sourcing from is probably a /bin/sh script, not a Bash script proper?

Shouldn't you be using \x instead of \u? printf "%b\n" "\x5A" works fine in both cases for me.

(Totally different idea here, so I'm posting it as another answer.)

Try running these at the command line:

builtin printf "%b\n" "\u5A"
/usr/bin/env printf "%b\n" "\u5A"

printf is both a shell builtin and an executable, and you may be getting different ones depending on whether you source or run the script. To find out, insert this in the script and run it each way:

type printf

While you're at it, you may as well insert this line too:

echo $SHELL

That will reveal if you're getting different shells, per tripleee.

HAHA!!! I finally traced down the problem! Read ahead if interested (leave the page if not).

These are the only command that will translate \u properly:

. ./test.sh                         ## Sourcing the script, hash-bang = #! /bin/sh
. ./test.bash                       ## Sourcing the script, hash-bang = #! /bin/bash
./test                              ## Running the script with no hash-bang

All of the following produce identical results in that they do NOT translate \u:

./test.sh                           ## Script is run from an interactive shell but in a non-interactive shell

## test.sh has first line: #! /bin/sh
/bin/sh -c "./test.sh"              ## Running the script in a non-interactive sh shell
/bin/sh -lc "./test.sh"             ## Running the script in a non-interactive, login sh shell
/bin/sh -c ". ./test.sh"            ## Sourcing the file in a non-interactive sh shell
/bin/sh -lc ". ./test.sh"           ## Sourcing the file in a non-interactive, login sh shell

## test.bash has first line: #! /bin/bash
/bin/bash -c "./test.bash"          ## Running the script in a non-interactive bash shell
/bin/bash -lc "./test.bash"         ## Running the script in a non-interactive, login bash shell
/bin/bash -c ". ./test.bash"        ## Sourcing the file in a non-interactive bash shell
/bin/bash -lc ". ./test.bash"       ## Sourcing the file in a non-interactive, login bash shell

## And from ***tripleee*** (thanks btw):
/bin/sh --norc; . ./test.sh         ## Sourcing from an interactive sh shell without the ~/.bashrc file read
/bin/bash --norc; . ./test.bash     ## Sourcing from an interactive bash shell without the ~/.bashrc file read

The only way to get proper translation is to run the script without a hash-bang... and I finally figured out why! Without a hash-bang my system chooses the default shell, which btw is NOT /bin/bash... it turns out to be /opt/local/bin/bash... two different versions of bash!

Finally, I removed the OSX /bin/bash [v3.2.48(1)] and replaced it with the MacPorts /opt/local/bin/bash [v4.2.10(2)] and now running the script works! It actually solved about 10-15 other problems I've had (like ${var,,}, read sN1 char, complete -EC "echo ' '", and a host of other commands I have scattered throughout my scripts, ~/.bashrc amd ~/.profile). Honestly, I really should have noticed when my scripts using associative arrays suddenly crapped out on me... how stupid can I get!?

I've been using bash v4 for a looong time now, and my Lion upgrade went and down-graded bash back to v3 (get with the program Apple!)... ugh, I feel so ashamed! Everyone still using bash v3, upgrade!! bash v4 is has many, many beautiful upgrades over version 3. Type bash --version to see what version you are running. One advantage is now bash can translate \uHEX into Unicode!

Try removing the space in the first line, I seem to recall that can cause problems. Offhand I'd guess that because of that space, you're not getting bash, but sh.

Glad you solved it. Still, you might be looking for a portable solution.

Assuming you are always using the same formatting string, we can just discard it, and use something like this;

printf () {
  # Discard format string
  shift
  perl -CSD -le '
    print map { s/^\\u//; chr(hex($_)) } @ARGV' "$@"
}

Edit to add: You would simply add this function definition at the beginning of your existing script, overriding the builtin printf. Obviously, if you also use printf for other stuff, this special-purpose replacement isn't good enough.

You could rename the function to uprintf or something, still. It merely translates a sequence of hex codes to the corresponding Unicode characters, discarding any \u prefix.