I am trying to better understand printf so I read multiple pages on this command, but I also stumbled upon different behavior of %q directive. Namely, stated on this page : > What is the difference between printf of bash shell, and /usr/bin/printf? The main difference is that the bash built-in printf supports the %q format specifier, which prints escape symbols alongside characters for safe shell input, while /usr/bin/printf does not support %q. *** It behaves different, but I may not fully understand what the sentence means. The following is *different*, yet I think equally effective:

info printf | grep -A 4 '%q'

> An additional directive %q, prints its argument string in a format that can be reused as input by most shells. Non-printable characters are escaped with the POSIX proposed $'' syntax, and shell metacharacters are quoted appropriately. This is an equivalent format to ls --quoting=shell-escape output.

$ touch 'printf testing %q.delete'
# no output

$ \ls -l printf\ testing\ %q.delete
-rw-rw-r-- 1 vlastimil vlastimil 0 Jun 15 23:21 'printf testing %q.delete'

$ /usr/bin/printf '%q\n' printf\ testing\ %q.delete
'printf testing %q.delete'

$ printf '%q\n' printf\ testing\ %q.delete  # Bash builtin
printf\ testing\ %q.delete

*** Can anyone elaborate on these differences, maybe adding in which scenarios it is advised to use this or that one? Thank you.

When I execute the c file

#include 
#include 

int main(){
        printf("before the system call. I am too excited!\n");
        system("ps");
        printf("after the system call. Look what you have done!\n");
}

I get the output

before the system call. I am too excited!
    PID TTY          TIME CMD
    140 pts/0    00:00:03 zsh
   1613 pts/0    00:00:00 system
   1614 pts/0    00:00:00 sh
   1615 pts/0    00:00:00 ps
after the system call. Look what you have done!

but when I remove the '\n' from the first printf(), I get

PID TTY          TIME CMD
    140 pts/0    00:00:03 zsh
   1590 pts/0    00:00:00 system
   1591 pts/0    00:00:00 sh
   1592 pts/0    00:00:00 ps
before the system call. I am too excited!after the system call. Look what you have done!

So what I am asking is, how the '\n' character changes the printf() output, and it led me to thinking, does the program stores the text in some buffer before printing, or just prints with the go? I am getting the expected output for the second if I add fflush(stdout) for before the system("ps"), but I want to understand the exact mechanism. When I add fflush(stdout), it cleared the buffer of the first printf() and the output of system("ps") was appended with it, but without it, what is exactly happening?

Bash printf floating number formatting (with %f or %g) is suddenly completely wrong, and changing all the time. An example output:

$ export LC_ALL=C
$ printf '%g\n' 1
1.20739e+3531
$ printf '%g\n' 1
4.50784e-4778
$ printf '%g\n' 1
1.20739e+3531
$ printf '%g\n' 1
-2.71289e-809
$ printf '%g\n' 1
1.3505e+3136
$ printf '%g\n' 1
7.19546e+2880
$ printf '%f\n' 1
0.000000
$ printf '%f\n' 1
-19222373783767455764509969957314767706032565305205751517976389011586356910287283735873496366975075385910809025031233228909443235485943598697862160225065543796566324326303010027986380740507313362109478389280032720809755605977575591712977484833714421549464179548312816619669691695969675768618124142786377660052446990574866227828104911221712770547544994592495621702453486060768120985842267603349960735550433657827156688542311891238932963870595675569407105652838611000368894193915118759451716250477855842495787217908770520219596001805968923516834815448319714521179606192054239712352794281273655344703644255690153172028191401140768961585354430400117766273628103129509500449952562778071128862373050266582261154261590345666202936676378315868263637718127652344391988248019089245237502067305800855582602326233046151999935749805709388443164385685796904118233897433899895164143403147924128628840995216653448904704.000000
$ printf '%f\n' 1
-1535939692251970798780814048195400843655654544941633379309930935432267368465724365567117453392273362651582982424721184431169329486749020702578930669204206705946793193732917405530938783202632819503328225917797530425669645856818642162664722510713747202433401571296943178862058175872487260754269792220244257605097737000140353828109440097622967061126831273879953063844519410176251996107980841451192710472925184.000000
$ printf '%f\n' 1
-559936185544451048996856397218869061556420299014564433770484452018186365447891968084773838558135844864.000000

It is bash builtin that is being used, as I can see when typing command -v printf. alias printf says "not found". I have the binaries at /bin/printf and /usr/bin/printf that behave normally. Awk and Python equivalent commands behave normally. Interestingly, when using sh, it's fine too. I am on Debian testing, and I tried to apt upgrade and reboot but the bug persists. Bash version is GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu). I tried apt reinstall bash without success. Yesterday for another reason I did a apt-get dist-upgrade. What have I done?! It's wild. [EDIT: additional debugging below] - Run a Memtest86+ for 12 passes, detected no error. - recompiled [Bash 5.2.32 from GNU](https://www.gnu.org/software/bash/) , it has the problem. - tried as another user. - This bug has been reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078556 . I guess I am going to continue this topic with the Debian bug report system. Here is the content of /etc/apt/sources.list:

deb https://deb.debian.org/debian/  testing main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/  testing main contrib non-free non-free-firmware contrib

deb http://security.debian.org/debian-security  testing-security main contrib non-free non-free-firmware contrib
deb-src http://security.debian.org/debian-security  testing-security main contrib non-free non-free-firmware contrib

and I also have /etc/apt/preferences.d/security as suggested in [Best practices for Testing users](https://wiki.debian.org/DebianTesting#Best_practices_for_Testing_users) :

Package: src:chromium src:firefox src:firefox-esr src:linux src:linux-signed-amd64
Explanation: these packages are always security updates updated in unstable first
Pin: release a=/^(unstable|unstable-debug|buildd-unstable|buildd-unstable-debug)$/
Pin-Priority: 980

The command

-sh
printf "%d, %f, %o, %s, %x, %X\n" 380 380 380 380 380 380

outputs

380, 20689...2384.000000, 574, 380, 17c, 17C

where the second output is a very large (with almost thousand digits) float. When I tried

-sh
printf "%f" 380

I got

-0.000000

I do not understand what's happening! When using %f together with other format specifiers it gives a very large float, while when using it alone, it outputs -0 (!), none of which is expected. Can someone explain the reason? For reference, I am on a Kali Linux WSL.

I'm reducing the question to (I believe) the simplest case. Let's say I have a script myscript.sh with the following contents: #!/bin/bash IFS='%20' echo "$*" If I run the command as follows, the output will look like: me@myhost ~ $ ./myscript.sh fee fi fo fum fee%fi%fo%fum This is expected behavior, as described in the bash man page: * Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, it expands to a sin- gle word with the value of each parameter separated by the first character of the IFS special variable. That is, "$*" is equiva- lent to "$1c$2c...", where c is the first character of the value of the IFS variable. If IFS is unset, the parameters are sepa- rated by spaces. If IFS is null, the parameters are joined without intervening separators. However, what I would like to get is the output: fee%20fi%20fo%20fum Thus using a multiple character separator field rather than a single character. Is there a way to do this that is native to bash? ---------- **UPDATE:** Based on the data from mikeserv below, and the writeup at https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo , I ended up doing the following (again reduced to simplest case as in the example above): #!/bin/bash word="$1" shift if [ "$#" -gt 0 ] ; then word="$word$(printf '%%20%s' "$@")" fi printf '%s\n' "$word" unset word

We are in a concurrent scenario where we have **n** concurrent processes. By using a synchronization policy (e.g., using pipes or signals), each process can print using *printf("string\n")* only if it receives a token from the previous process, ensuring a specific printing order. When stdout is attached to a terminal (e.g., a console), the expected printing order is respected, meaning processes print in the exact order defined by the synchronization policy. However, when stdout is piped or redirected to a file or another process, the resulting printing order may not be respected, even though the processes still follow the synchronization policy correctly. We know that *printf* is buffered by default, meaning it does not immediately write to stdout but instead accumulates output in a buffer before flushing it. In a concurrent environment, it seems the operating system writes each process's buffer in an order independent of the intended synchronization policy, causing out-of-order prints. This is unexpected given that each process follows the policy correctly. However, this problem does not occur if one of the following solutions is implemented: 1. Forcing a flush after each call to printf using *fflush(stdout)*; 2. Disabling buffering for stdout in each child process using setvbuf(stdout, NULL, _IONBF, 0);. 3. Using the system call write(1, "string\n", strlen("string\n")); instead of printf, since write bypasses buffering and directly writes to stdout. Does anyone know why this happens? What is the operating system's policy regarding this?

I already posted add escape character with bash . I need script to this for every line in a file that starts with {@codeBlock so {@codeBlock: TEstBigquerry.buildPicks} should look like \{@codeBlock:\ TEstBigquerry.buildPicks\} My script #!/bin/bash file=clfields.mdx while read -r line; do if [[ "${line::11}" == '{@codeBlock' ]]; then printf '%q\n' "$line" else echo "$line" fi done < clfields.mdx Terminal output is ok but the file stays the same. Why?

In Linux in Bash in a for loop i do: ... ; do echo "$i --> $i-new" ; ... The output is than something like this: file1 --> file1-new file2 --> file2-new ... file9 --> file9-new file10 --> file10-new file11 --> file11-new how to become an output like this: file1 --> file1-new file2 --> file2-new ... file9 --> file9-new file10 --> file10-new file11 --> file11-new ?

With

awk '{ printf "%-15s %s\n", $1, $2 }' renamed | sort -V

... I get good output from the file renamed. It looks like:

file1           file1.new

But I want to have the output changed to this:

file1           -->  file1.new

I want to add --> at position 15 in each line. How to do that?

With version GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu) in present Debian testing this command: $ printf '%010f\n' '1234' 000.000000 Doesn't use the number given and changes on every execution? : $ printf '%010f\n' '1234' 000.000000 $ printf '%010f\n' '1234' -00.000000 $ printf '%010f\n' '1234' -483727882220210383673538789311734784068460135136461336086484727908638813056859257411855537705282271270980907616349527085348099018785353082643221259209294558156190448714309764451049347540471064551446885137304830478611003880772998267972492798437861990242385390167399221730525636524535959100898865048044621829532180872869831407033533680957149104798943111261125290846584672637786950588494241537852501370987086890557439435578999950651169388180476906711478049091875710028706657130770652700584029129393783335159019276229170433952983735319574924819265320406630232536315336832562784656716950007939401275466624481927781927258325705879156330466999432612166518529539015750123768161816142453794507679229993846158691958525270639720288023359751521266391315728694060032591665637983258824799749300768142902211449165371138800414916337009245091261553826987554933951337065582043260565800658802960164297014952829986461975404403328316973961329623423683108873863706900026374773894180497513448143048382250942260806514095625959417231557222342591236652512686787828803609697693656123275076808865225369983011037611625663587582203365010071225681027800095427631778822391073362620068182757407019491657182878003911077240783559336224719331241350462550966676226233143230279692283620645084683412441335955962689659909099953181023376906230488367104.000000 1.- Is this reproducible? Yes, see bug report https://unix.stackexchange.com/questions/783623/bash-printf-float-formatting-became-nonsensical-and-random (thanks steeldriver) 2.- Where is bash reading those values? From uninitialized memory locations as this command reports: $ valgrind bash -c 'printf %f 2' **Solution(s)** 1.-Use Debian stable (which has an older bash version without this bug). 2.- Install a different version of bash. This is the way I did it, I believe that this work, but I can not give any guarantee. Since installing an older version might reproduce older bugs, it is better to install a newer version. The list of bash versions available for general consumption are here: https://ftp.gnu.org/gnu/bash/ Download the bash source and compile it: curl -O https://ftp.gnu.org/gnu/bash/bash-5.2.37.tar.gz tar xvf bash-5.*.tar.gz cd bash-5.2.37 ./configure make And then install it manually: # mv /bin/bash /bin/bash.bak And copy the bash file compiled above to /bin/bash. Reboot to ensure all copies of bash have been flushed from memory. Try: $ LC_ALL=C bash -c "printf '%5.15f\n' '2.1'" 2.100000000000000 And confirm that the version is correct: $ bash --version GNU bash, versión 5.2.37(1)-release (x86_64-pc-linux-gnu)

Whenever I pipe some output that is updating (say with \r), e.g. to a pager (less), or to colourise parts of it, the pipe seems to drop the lines that are updating. Any idea how to preserve the updating behaviour while do whatever else I want to do? MWE:

(
  echo num1;
  for i in {01..99}; do
    printf "num2: %s\r" $i;
    sleep 0.5;
  done
)

Normally the above shows:

num1
num2: NN

where NN counts from 01 to 99. But if I pipe the above to less, I only see the line num1, or say I pipe it to sed to make all occurences of num bold like this:

(
  ...
) | sed -e "s/num/$(tput bold)&$(tput sgr0)/g"

I only see "**num**1", the line with "num2" disappears. How can I keep the second line?

A well-formed printf usually has a format to use:

$ var="Hello"
$ printf '%s\n' "$var"
Hello

However, what could be the security implications of not providing a format?

$ printf "$var"
Hello

As the variable expansion is quoted, there should not be any issues, are there?

printf %s%s one two prints onetwo but I would like oneonetwotwo How can I do that?

I have an array snapshots=(1 2 3 4) When I run printf "${snapshots[*]}\n" It prints as expected 1 2 3 4 But when I run printf "${snapshots[@]}\n" It just prints 1 without a newline. My understanding is that accessing an array with @ is supposed to expand the array so each element is on a newline but it does not appear to do this with printf while it does do this with echo. Why is this?

I'm not quite versed on the terminal, but the few things I've known and read lead me to believe that printf is much more powerful and confortable than echo but work for similar (if not same) purposes. So I asked myself, is it sensible to alias echo to printf so I can forget about any issues with echo? Or is there something I don't see like portability or else? If needed, system is Ubuntu 20.04 running on WSL2 on Windows 10.

jq has built-in ability to convert numbers to string or concatenate strings. How can I format strings inside jq similar to printf like padding (%4s). For example, how can I force number to occupy 10 char spaces with left alignment? echo '{"title" : "A sample name", "number" : 1214}' | jq '(.title) + " " + (.number | tostring)'

In Zsh 5.9, we can use printf to shell escape a string:

$ printf '%q' 'One! Two'

One\!\ Two

This produces the correct output of escaping the ! and the space. Now let’s make it as a script:

#!/bin/zsh

printf '%q' "${1}"

Now if we run it, the ! is **not** escaped but the space is:

$ ./my-script 'One! Two'

One!\ Two

If I change the script to /bin/bash (version 3.2), it correctly escapes the ! and space. Is this a Zsh bug, or is there some subtle detail I’m missing?

Instead of the following printf '%s\t%s\t%s\t%s\n' 'index' 'podcast' 'website' 'YouTube' I want to store the printf output in a Results variable, how can I do this?

The ASCII hex code for a zero is 0x30. Hence, you can print a zero by doing printf '\x30', and it will print a zero. If you put this into a shell script called myScript.sh, and then execute ./myScript.sh, it will also print a zero. But if you execute sh -c printf '\x30' or alternatively, sh myScript.sh, you will instead get the literal characters "\x30", rather than having it be interpreted as a single byte. Why is that? (Behavior has been observed on multiple machines, all of which I believe are running bash).

How do I get printf to output hex characters when run from a script? Suppose I am at the prompt and type **printf "\x41\x42"** the output I get AB% However if I have a script containing that line i.e. cat test.sh produces printf "\x41\x42" But executing the script **./test.sh** produces \x41\x42% How do I get the script to produce the same results as from the shell prompt?