I like to use set -x in scripts to show what's going on, especially if the script is going to run in a CI/CD pipeline and I might need to debug some failure post-hoc. One annoyance with doing this is that if I want to echo some text to the user (e.g., a status message or "I'm starting to do $X") then that message gets output twice - once for the echo command itself being echoed, and then once as the output of that echo command. What's a good way to make this nicer? One solution is this:

set -x

... bunch of normal commands that get echoed

(
  # Temporarily don't echo, so we don't double-echo
  set +x
  echo "Here is my status message"
)

... rest of commands get echoed again

But the two problems with that are 1. That's a lot of machinery to write every time I want to tell the user something, and it's "non-obvious" enough that it probably requires the comment every time 2. It echoes the set +x too, which is undesirable. Is there another option that works well? Something like Make's feature of prepending an @ to suppress echoing would be great, but I've not been able to find such a feature in Bash.

Does anybody know why this is happening and how to fix it?

me@box:~$ echo "eyJmb28iOiJiYXIiLCJiYXoiOiJiYXQifQ" | base64 -di
{"foo":"bar","baz":"bat"}base64: invalid input

When I use echo $’hi\nhi’ > /etc/list.list in an executable script text file I create comprising multiple commands on Kali Linux 2020.4 Live USB it: 1. Includes the $ in the files text while disappearing the 2 ’’ symbols. 2. Does not work to create a new line, separating the 2 hi’s from each other, instead just showing the \n with no separation at all. but when I use the same command outside of the executable or in the plain terminal it works. Did Kali 2020.4 change from 2020.3 to not allow the echo formatting I use within an executable text file, because it use to work flawlessly? Is there some other command I can use for echo that will create a new line in a 1 line command?

When you want to redirect both stdout and stderr to the same file, you can do it by using command 1>file.txt 2>&1, or command &>file.txt. But why is the behavior of command 1>file.txt 2>file.txt different from the above two commands? The following is a verification command. $ cat redirect.sh #!/bin/bash { echo -e "output\noutput" && echo -e "error" 1>&2; } 1>file.txt 2>&1 { echo -e "output\noutput" && echo -e "error" 1>&2; } 1>file1.txt 2>file1.txt { echo -e "error" 1>&2 && echo -e "output\noutput"; } 1>file2.txt 2>file2.txt { echo -e "output" && echo -e "error\nerror" 1>&2; } 1>file3.txt 2>file3.txt { echo -e "error\nerror" 1>&2 && echo -e "output"; } 1>file4.txt 2>file4.txt $ ./redirect.sh $ echo "---file.txt---"; cat file.txt;\ echo "---file1.txt---"; cat file1.txt; \ echo "---file2.txt---"; cat file2.txt; \ echo "---file3.txt---"; cat file3.txt; \ echo "---file4.txt----"; cat file4.txt; ---file.txt--- output output error ---file1.txt--- error output ---file2.txt--- output output ---file3.txt--- error error ---file4.txt---- output rror As far as the results are seen, it looks like that the second echo string overwrites the first echo string when you run command 1>file.txt 2>file.txt, but I do not know why it will. (Is there a reference somewhere?)

It is my understanding that the LANG and LC_CTYPE environment variables define the encoding used by shell commands when writing to stdout. However, after executing LANG=de_DE.iso88591 LC_CTYPE=de_DE.iso88591 echo "ä" > test.txt in the bash shell, the text.txtfile contains an "ä" encoded in UTF-8, not in ISO 8859-1. de_DE.iso88591 appears when running locale -a. What am I missing here? I would like to use the ISO8859-1 encoding. --- Additional information: My default / current locale is:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

After executing export LANG=de_DE.iso88591 the locale is

LANG=de_DE.iso88591
LC_CTYPE="de_DE.iso88591"
LC_NUMERIC="de_DE.iso88591"
LC_TIME="de_DE.iso88591"
LC_COLLATE="de_DE.iso88591"
LC_MONETARY="de_DE.iso88591"
LC_MESSAGES="de_DE.iso88591"
LC_PAPER="de_DE.iso88591"
LC_NAME="de_DE.iso88591"
LC_ADDRESS="de_DE.iso88591"
LC_TELEPHONE="de_DE.iso88591"
LC_MEASUREMENT="de_DE.iso88591"
LC_IDENTIFICATION="de_DE.iso88591"
LC_ALL=

Then running echo "ä" > test.txt yields the same result ("ä" in the file being encoded in UTF-8).

I'm in Bash, in Linux Mint. If I execute

{ echo 1 || >&2 echo "[ $? ]" ; } | echo

an empty line is printed. Note that Bash interprets echo as a built-in. But if I execute

{ /bin/echo 1 || >&2 echo "[ $? ]" ; } | /bin/echo

it outputs

[ 141 ]

Per man bash we know that that 141 means it received signal 13, and per man 7 signal that it means there was a SIGPIPE signal generated. In man 7 pipe we read that > [i]f all file descriptors referring to the read end of a pipe have been closed, then a write(2) will cause a SIGPIPE signal to be generated for the calling process. So I conclude that in the second case "all file descriptors referring to the read end of a pipe have been closed", whatever it should mean for the /bin/echo. But why is the output different in the case of Bash's echo?

I'm pretty new to Linux in general, so I'm not too familiar with do's and don'ts of some commands. I wanted to create a file and noticed that: touch file.txt ` creates a file, but so does: echo >> file.txt and also > file.txt The files created with ">" and "touch" are both 0 bytes but the file created with "echo" is 1 byte. Why are the files different sizes and what's the best way to create a file? When should someone create a file with "echo" instead of "touch" or ">"?

What is the difference between these three commands? echo date echo "date" echo 'date' I am confused on what the differences actually are. I think that when the ' are around it means that it is a string, therefore echo would literally output the string date instead of displaying the date?

When using the command echo $100, I got the output 00 while if I give echo $d00 as the command, it gives an empty line! Why? Is there a way inside for the bash to interpret the two differently?

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

I have the following code snippet:

#!/bin/sh 

if [ $1 = hi ]; then 
    echo 'The first argument was "hi"'
else
    echo -n 'The first argument was not "hi" -- ' 
    echo It was '"'$1'"'
fi

And I don't know what the flag -n after echo in the else statement stands for, does anyone knows the answer? Thank you very much!

If I run export TEST=foo echo $TEST It outputs foo. If I run TEST=foo echo $TEST It does not. How can I get this functionality without using export or a script?

I tried to create a script by echo'ing the contents into a file, instead of opening it with a editor echo -e "#!/bin/bash \n /usr/bin/command args" > .scripts/command The **output**: > bash: !/bin/bash: event not found I've isolated this strange behavior to the bang . $ echo ! ! $ echo "!" bash: !: event not found $ echo \#! #! $ echo \#!/bin/bash bash: !/bin/bash: event not found - Why is bang causing this? - What are these "events" that bash refers to? - How do I get past this problem and print "#!/bin/bash" to the screen or my file?

Please explain why 1 4 5 6 is displayed for the last four echo statements? I hit this by accident once, but I am now curious as to why this behavior occurs. These statements work as expected (for me). $ echo [ 9876543210 ] [ 9876543210 ] $ echo These echo statements consistently display 1 4 5 6. Is there something special about these numbers? $ echo 1 4 5 6 $ echo [abcd9876543210ghi] 1 4 5 6 $ echo [-123456-] 1 4 5 6 $ echo [-7654321-] 1 4 5 6 Thanks! * The possible duplicate is related and helpful, but not a duplicate. The possible duplicate is from the perspective of an rm command. This question is from the perspective of a perceived "weird behavior" of an echo command. The underlying answer for both is globbing. Someone searching for issues with an echo command would not easily find the rm question, but would more likely land here.

I understand I could use $LINENO while debugging bash script to print out line number. #!/bin/bash set -x PS4='${LINENO}: ' echo "hello" set +x Prints out the following if I run the script

$ ./script.sh
+ PS4='${LINENO}: '
4: echo hello
hello

That looks great. I can clearly see that the echo came from line 4. But, if I source the script, the line number gets somehow duplicated.

$ source script.sh
33: PS4='${LINENO}: '
44: echo hello
hello
55: set +x

Not sure what I'm doing wrong, but obviously my script doesn't have line numbers up to 33, 44, 55. It just seems like the line numbers are wrong. Why would sourcing the sourcing the script give this strange output?

We can use the command stty -echo with a bash shell script to prevent characters to be echoed to the console, e.g., for password input. Is there a way to print a * for each input character instead, and to delete them when pressing backspace?

I want to be greeted by

# #####################################################
# ### PostgreSQL 16.3 #################################
# #####################################################

on login to a postgres server. so I add

-bash
echo "# #####################################################"
psql -qAtc "SELECT version()" | awk {'print $1, $2'}
echo "# #####################################################"

to the ~/.bashrc. I now probably need some sort of echo with $(psql -qAtc "SELECT version()" | awk {'print $1, $2'}) but can not figure out how to add the leading/trailing # to it. Can somebody point me in the right direction here?

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.

I want create simple xml file using bash script ( not with dom ) but when I set value in the line then **echo** print the $lorem word and not the val **lorem=LOL** echo '$lorem' >> $MY_XML I also try this echo '\$lorem' >> $MY_XML echo '"$lorem"' >> $MY_XML echo '\"$lorem\"' >> $MY_XML but all these print the exactly the line and not the val please advice how to print the val $lorem ? as the following example LOL

With pulseaudio, it was easy to load a module for microphone noise reduction. This link explains it clearly: I want to add rnnoise as a plugin of pipewire to cancel the noise of the microphone for all users. I'm looking for a minimalist solution and would like to avoid applications. Like this one: