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.

After reading ilkkachu's answer to this question I learned on the existence of the declare (with argument -n) shell built in. help declare brings: > Set variable values and attributes. > > Declare variables and give them attributes. If no NAMEs are given, > display the attributes and values of all variables. > -n ... make NAME a reference to the variable named by its value I ask for a general explanation with an example regarding declare because I don't understand the man. I know what is a variable and expanding it but I still miss the man on declare (variable attribute?). Maybe you'd like to explain this based on the code by ilkkachu in the answer: #!/bin/bash function read_and_verify { read -p "Please enter value for '$1': " tmp1 read -p "Please repeat the value to verify: " tmp2 if [ "$tmp1" != "$tmp2" ]; then echo "Values unmatched. Please try again."; return 2 else declare -n ref="$1" ref=$tmp1 fi }

**How do I get the FZF Preview Window to Display Functions from my Current Bash Environment?** I want to list my custom bash functions using FZF, and view the code of a selected function in the FZF Preview Window. However, it does not appear that the bash enviroment used by FZF to execute my command can see the functions in my terminal bash environment. For example:

$ declare -F | fzf --preview="type {3}"

/bin/bash: line 1: type: g: not found

However, the following works:

$ declare -F

declare -f fcd
declare -f fz
declare -f g

$ type g
g is a function
g ()
{
    search="";
    for term in $@;
    do
        search="$search%20$term";
    done;
    nohup google-chrome --app-url "http://www.google.com/search?q=$search " > /dev/null 2>&1 &
}

declare -F | fzf --preview="echo {3}"

g # my function g()

One reason I suspect that the FZF Preview Window environment may not be able to see my terminal environment is because they have different process ID's.

$ echo $BASHPID

1129439

$ declare -F | fzf --preview="echo $BASHPID"

1208203

**How do I get the FZF Preview Window to Display Functions from my Current Bash Environment?**

If I want to get a brief usage message for a bash builtin, I can use help at a command prompt, e.g. $ help export export: export [-fn] [name[=value] ...] or export -p Set export attribute for shell variables. Marks each NAME for automatic export to the environment of subsequently executed commands. If VALUE is supplied, assign VALUE before exporting. Options: -f refer to shell functions -n remove the export property from each NAME -p display a list of all exported variables and functions An argument of `--' disables further option processing. Exit Status: Returns success unless an invalid option is given or NAME is invalid. How can I do this in zsh? I've tried % export --help zsh: bad option: -e and % help export zsh: command not found: help Also the word "help" isn't anywhere in man zshbuiltins.

Why does echo "$(fc -l -1)" show the previous command, but echo "$(fc -l -1 | cat)" show the current command?

$ testfc () {
>     echo "$(fc -l -1)"
>     echo "$(fc -l -1 | cat)"
> }

$ echo foo
foo
$ testfc
1820     echo foo
1821     testfc

## More detail I was testing things for [a rabbit-hole question](https://unix.stackexchange.com/questions/794387/multiline-command-substitution-syntax-errors-with-mysterious-1) and ended up down another rabbit hole. I created this function to try different ways of accessing the previous or current command history number with the [fc] and [history] built-ins:

testfc () {
    printf 'fc1\t';        fc -l -1
    printf 'fc1|\t';       fc -l -1 | cat
    printf '(fc1)\t%s\n'   "$(fc -l -1)"
    printf '(fc1|)\t%s\n'  "$(fc -l -1 | cat)" # this one is weird
    printf 'fc0\t';        fc -l -0
    printf 'fc0|\t';       fc -l -0 | cat
    printf '(fc0)\t%s\n'   "$(fc -l -0)"
    printf '(fc0|)\t%s\n'  "$(fc -l -0 | cat)"
    printf 'hist\t';       history 1
    printf 'hist|\t';      history 1 | cat
    printf '(hist)\t%s\n'  "$(history 1)"
    printf '(hist|)\t%s\n' "$(history 1 | cat)"
    str='\!'
    printf '@P\t%s\n'      "${str@P}"
    printf 'HC\t%s\n'      "$HISTCMD"
}

Generally, fc -l -0 & history 1 show the current command, and fc -l -1 shows the previous command. Their outputs don't change when run in a $() subshell or piped through cat. *Except* "$(fc -l -1 | cat)"!

1831 $ echo foo
foo

1832 $ testfc
fc1     1831     echo foo
fc1|    1831     echo foo
(fc1)   1831     echo foo
(fc1|)  1832     testfc   # <-- WHAT?
fc0     1832     testfc
fc0|    1832     testfc
(fc0)   1832     testfc
(fc0|)  1832     testfc
hist     1832  2025-05-02 15:10:59  testfc
hist|    1832  2025-05-02 15:10:59  testfc
(hist)   1832  2025-05-02 15:10:59  testfc
(hist|)  1832  2025-05-02 15:10:59  testfc
@P      1832
HC      1832

1833 $ fc -l -2
1831     echo foo
1832     testfc

## Context

$ echo $BASH_VERSION
5.2.37(1)-release
$ type fc
fc is a shell builtin
$ type history
history is a shell builtin
$ type cat
cat is /usr/bin/cat

I was plodding along, working on a shell script, and I've just learned something that I found *surprising*. I'm presenting it here as a Question because I'd like to learn if there's some way to avoid this. Here's the *scenario*: cd to a folder that is defined as a variable; except the variable name is spelled incorrectly in the cd command:

$ TGT_FLDR=/home/seamus/logs/
$ cd $TGT_FLDF
$ echo $?
0
$ pwd
/home/seamus
$

I learned of this while testing a script:

TGT_FLDR=/home/seamus/logs/
...
cd $TGT_FLDF
if [ -n "$(ls -A)" ]; then
    rm *
fi
### OUCH!!!

If I had quoted "$TGT_FLDF" (as I probably should have) cd still fails. If the pwd happens to be somewhere other than ~; cd "fails" in a **different way**, depending upon whether or not the variable is quoted. Note that in neither case does cd throw an error; this makes the error [*pernicious*](https://dictionary.cambridge.org/dictionary/english/pernicious) in that it cannot be trapped in a test ([]).:

$ pwd
/home/seamus/logs/testing
$ TGT_FLDR=/home/seamus/logs/
$ cd "$TGT_FLDF"               # var quoted
$ echo $?
0
$ pwd
/home/seamus/logs/testing
$ cd $TGT_FLDF                 # var unquoted
$ echo $?
0
$ pwd
/home/seamus
$

This *struck me* as rather dangerous behavior (primarily b/c $? is 0). Since cd is a bash *built-in* (at least on my system), I checked cd --help. One item stood out: > If the directory is not found, and the shell option `cdable_vars' is set, the word is assumed to be a variable name. If that variable has a value, its value is used for DIR. This statement makes little sense to me, but it *suggests* that there is a *"shell option"* cdable_vars defined somewhere, that it's defined, and may be defined as $HOME. I think I'd like to change the value of cdable_vars, but where is this shell option defined?

I wonder why a command that *executes commands from a file in the current shell* is named source. I can't see a relation between **run commands in the current shell** and the meaning of the english word **source**. Is there a history behind that name?

I am trying to add this to my ~/.bashrc and test for some commands, that already have aliases.

command -pv

but it seems like the -p option that is supposed to force a path search is getting ignored. Not sure if it's a bug to report so I decided to inquire in case i'm missing anything. **Tests**

Bash Version: 5.2
Patch Level: 37
Release Status: release

I make sure its the shell builtin

$ type command
command is a shell builtin

$ command --help
command: command [-pVv] command [arg ...]
    Execute a simple command or display information about commands.

    Runs COMMAND with ARGS suppressing  shell function lookup, or display
    information about the specified COMMANDs.  Can be used to invoke commands
    on disk when a function with the same name exists.

    Options:
      -p    use a default value for PATH that is guaranteed to find all of
            the standard utilities
      -v    print a description of COMMAND similar to the `type' builtin
      -V    print a more verbose description of each COMMAND

    Exit Status:
    Returns exit status of COMMAND, or failure if COMMAND is not found.

Works on aliases

$ command -v pacman
alias pacman='pacman --color auto'

$ command -v grep
alias grep='grep --color=auto'

But completely ignores '-p' however specified.

$ command -pv grep
alias grep='grep --color=auto'

$ command -p -v grep
alias grep='grep --color=auto'

Here, I tried to sneak in an unknown option to make sure it detects '-p' but simply ignores it.

$ command -p -v -x grep
bash: command: -x: invalid option
command: usage: command [-pVv] command [arg ...]

**Extra notes** In the zsh shell, everything seems to work fine, the -p option is treated as it should (I am not including zsh tests because this is about bash).

Where can I find more information about the command(?) print since I don't receive a result when I input man print? For example, in the zsh I can do the following: $ print "Hello, world\!" Hello, world! I've seen print -P foo and print -n bar used among other flags and have no idea what they mean nor do I know where to look for further information. So we have two questions really: 1. Where does print come from and where can I find documentation for it? 2. Where does one find documentation for similar items that are not to be found in the man pages? NOTE: For clarification, I'm not trying to print a sheet of paper. I am also aware of printf, which allows for formatted output and has a man page.

Input:

hello
enrico

output:

ocirne
olleh

To do this, I can simply tac a file and pipe the output to rev (or the other way around), so one function that does the job is just this:

revtac() { tac "$@" | rev; }

Is there a built-in function for the job? I suspect that this could potentially break something, as it would reverse ` and ` on Windows-generated files, but I'm still interested.

I want to customize the functionality of cd command as per my needs. I defined the following function - function cd () { cd "$@" && pushd "$@"; } The intent of this function is to automatically push the directory onto the stack so that it saves me the effort to manually type pushd . every time. However, the above function is an infinitely recursive function, as the call to cd is interpreted to be the function itself and not the cd built-in. How do I reference the cd built-in in this function? I know that aliases can be escaped using \. What is the way to escape functions or reference built-ins in a more explicit way? *Note: I do not want to rename my function to anything else.*

I'm writing a script that I run directly, "source" from the bash console, or cut/paste as a sequence of commands into a console from an editor window. The script or its pasted commands may encounter an error and need to exit; when it does, I do not want to exit the console. The problem is pasting commands into the terminal because each line is treated independently: aborting on one line will still execute the subsequent lines. I do not want to rely on external commands, only Bash. I have come up with a way to do this, but am wondering if there's an easier/better way. Put this into a script then either run it, source, it, or paste the commands into a console window:

#!/bin/bash
# test of exit from running, sourcing, or pasting a series of commands

# return fails implies either running or pasting; if not running, then pasting
shopt -s expand_aliases
SAVEOPTS=/tmp/$$.bashopts
saveopts () {
	set | egrep -v '(BASHOPTS|BASH_VERSINFO|EUID|PPID|SHELLOPTS|UID)=' >$SAVEOPTS
	alias >>$SAVEOPTS
}
alias EXIT="{ echo 'exit required, terminating' ; \
	return 2 >&/dev/null || \
	[[ '${0}' == '${BASH_SOURCE}' ]] && exit 2; \
	saveopts ; exec bash --rcfile $SAVEOPTS; }" 

# usage
echo "good stuff"			# commands that should pass
true || EXIT				# example of a successful command
echo "more good stuff"		# another good command
false || EXIT				# failed command
echo "SHOULD NOT SEE THIS"	# do not want this to run

I'm using this in GNU bash, version 5.2.15(1). How it works - call EXIT when you wish to terminate. 1. If sourcing the script, e.g., source 1.sh, the return 2 in the alias causes the sourcing to stop. 2. If running the script directly, e.g., bash 1.sh or just ./1.sh, the return 2 fails and falls through to the second condition that checks whether the name of the process is the name of the script. This succeeds, resulting in an exit 2. 3. If pasting, these first two conditions don't take effect, so instead it re-execs the current shell bringing back in the previous settings. Using exec preserves the PID of the shell. (The grep -v's are for unsettable options and is done to prevent the shell from trying to set these.) This generally feels fragile. Is there a better way? I'd like to have EXIT as the command, but am open to eval something, or a function call, or something else, as long as it's relatively short. I also prefer not to depend on external commands (which I don't have installed) such as xclip. *Revisions to this post:* - Added the exec logic simplifying the entire thing - This is a different question than another question having to do with aliases and not terminating a list of pasted commands.

**UPDATE** Once again, I can't post an answer to my question! Clicking the button just triggers an error message: "Unable to load popup - please try again". So, I have no other choice than to share the solution like this:

="token="0"; if [[ "$input_path" =~ /$ ]]; then token="1"; input_path="${input_path%/}"; fi; cd "${input_path%/*}"; printf "$PWD/"; if [[ "$token" -eq 1 ]]; then printf "${input_path##*/}/"; else printf "${input_path##*/}"; fi"

Evaluation: 0:1 - bash exhaustion:unix philosophy If coding thoroughly is an ambition, the bash exhaustion way just proves that in this case it's far better to rely on unix philosophy, here meaning application of tool

, instead of replicating what it does with bash - you see, it works, but it's a mess, very complicated and a lot more code. ---- Use the tool

, from a certain working directory, setting the scope with a relative path, search for any files, and apply

-exec realpath

- will have the same working directory as

, unless using

-execdir

- on the resulting matches - relative paths - and output will be that same list of relative paths, but transformed into absolute paths. Out of curiosity: Can bash do this alone?

I've hacked on a lot of shell scripts, and sometimes the simplest things baffle me. Today I ran across a script that made extensive use of the : (colon) bash builtin. The documenation seems simple enough: > : (a colon) > : [arguments] > Do nothing beyond expanding arguments and performing redirections. The return status is zero. However I have previously only seen this used in demonstrations of shell expansion. The use case in the script I ran across made extensive use of this structure: if [ -f ${file} ]; then grep some_string ${file} >> otherfile || : grep other_string ${file} >> otherfile || : fi There were actually hundreds of greps, but they are just more of the same. No input/output redirects are present other than the simple structure above. No return values are checked later in the script. I am reading this as a useless construct that says "or do nothing". What purpose could ending these greps with "or do nothing" serve? In what case would this construct cause a different outcome than simply leaving off the || : from all instances?

I'm trying to sort out a bash command to convert a number from base 10 to an arbitrary base, using a specified set of characters (for example, to base 26 using letters a-z, although that's not actually my use-case). I *have* solved this problem before, but not in bash (which I have limited experience in), and not in quite some time. Any ideas?

I was reading an article on various Linux commands that can show location of programs in the search path, including which, type, and whereis. The article says that type is a built-in bash command, and when I run type type it indeed outputs "type is a shell builtin". However, when I run which type, instead of not output anything (which is the behavior in [this](https://askubuntu.com/questions/446580/why-does-type-which-say-that-which-is-hashed) AskUbuntu post), it outputs "/usr/bin/type". Is this different output of which caused by different distros since I uses Fedora instead of Ubuntu? In addition, why would there be a separate program called /usr/bin/type on my system, and what is the difference between it and the built-in bash command? In addition, I also noticed that there is a /usr/bin/cd program on my system while cd is also a built-in bash command. I also know the difference between the bash built-in time command and the /usr/bin/time program, but it seems that /usr/bin/type and built-in type command do almost the same thing on my system.

mapfile -t -u 7 arr < textfile gives me bash: mapfile: 7: invalid file descriptor: Bad file descriptor Other, more verbose, methods of reading files line-by-line do allow for such descriptor, e.g.

read_w_while() {
while IFS="" read -u 7 -r l || [[ -n "${l}" ]]; do
  echo "${l}"
done 7< textfile

The standard descriptor, 0, is used quite a lot. Does using such descriptor make scripting more secure from interference? My experience is that so far I only witnessed, I am a Ubuntu Desktop user, such interference when using while IFS="" read -u 7 ... with the descriptor 7. What might be the reasons of such interference.

I want to execute all commands within my script with command -p e.g.:

command -p pwd

Because there may be some command that I will execute within the script whose name is being used by some other custom user script and in this case the command command causes the system command to be executed and not the user's (this is a friendly explanation, if you want a technical understanding of what really happens behind the scenes, consult the man page) which is what I want. Well, so that I don't always have to literally type "command -p" at the beginning of the line every time I invoke any command within the script, is there any way to define the behavior of command -p globally in the script?

Please forgive my basic unix/linux scripting skill and poor English I am testing a script in the Linux VM, let's say it is work.sh. So I have to ssh to the VM ssh myname@theVm.domain.app with my access, then I need to run the script in my home folder [myname@theVm.domain.app ~]. work.sh param1 param2 When something goes wrong in the batch script, I can see the error but also get kicked out of the VM/ssh session Connection to myname@theVm.domain.app closed. so I have to log back in. I tried nohup, but I also like to have any error/log output to the console. What is the better way to handle this situation

I've created a simple C program like so: int main(int argc, char *argv[]) { if (argc != 5) { fputs("Not enough arguments!\n", stderr); exit(EXIT_FAILURE); } And I have my PATH modified in *etc/bash.bashrc* like so: PATH=.:$PATH I've saved this program as set.c and am compiling it with gcc -o set set.c in the folder ~/Programming/so However, when I call set 2 3 nothing happens. There is no text that appears. Calling ./set 2 3 gives the expected result I've never had a problem with PATH before and which set returns ./set. So it seems the PATH is the correct one. What's is happening?