what does "&" mean in the terminal

The Advanced Bash Scripting Guide (the last link in chrism01's post above) has a whole page specifically dedicated to describing all the reserved/special characters used in bash, and how they are used. Check it out.

http://www.tldp.org/LDP/abs/html/special-chars.html

The ABS teaches some stupid and some totally wrong things.
Do NOT use this.

The best bash guide out in the net.
Some very good snippets and good teaching.
The evergreen of problems. You have to read this about Quoting
Some very good snippets and nice ideas.
A quite new mailinglist about bash
If you want to read about the actual developments regarding bash
Some FAQs, giving snippets and explanations to the most common questions and day by day work.
And on freenode.net the channel #bash
Some developers of the bash hanging around here and are willingly to help you.

Note: ABS is outdated and teaches some wrong things.
DO NOT USE IT!

Most sites out there telling you wrong thins about bash.
Be careful!

Can anyone else verify what uhelp claims? I've seen the ABS recommended many times on this and other sites, and this is the first time I've seen negative criticism of it.

I seldom use ABS, preferring the GNU bash Reference, because it's hard to find things in it but I am not aware of any "wrong things" in it.

@uhelp: can you be specific?

This is from "help read":

-n nchars return after reading NCHARS characters rather than waiting for a newline, but honor a delimiter if fewer than NCHARS characters are read before the delimiter

from ABS read:

The -n option to read will not detect the ENTER (newline) key.

There are some more things, which aren't correct.

As I'm not anymore familiar with ABS and therefore did not find all these issues anymore.
Some of them might be have been corrected.

They claimed that the "cd" command would not set it's return value properly.
Prove this wrong with

mkdir -p a/b
cd a
printf $?'\n'
cd a
printf $?'\n'

They also claimed that using

cd //
pwd

does not work properly.
As "/" is just a path separator you can use "//", wherever you feel to.
It separates just e.g. /home//somebody the two dirs with a separator nothing and another separator.
It is very misleading to blame "cd" for this.
Correct is, that you have to take care about this thing, when writing code to parse a path.

I think this enough to be at least very critical when using ABS.
Use the links I posted earlier in this thread.

I agree with Knightron - "woh" & "over" my head (that's 'and').

I am almost bash illiterate, I understand a very few things.
But on the command line I have always related the '&' to end commands or join commands.

ie:

gedit ~/conky/myconky & conky -c ~/conky/myconky

which would:
1. open the file ~/conky/myconky in gedit, and
2. run 'myconky'

My favourite links for man pages in order:
Linux man pages - die.net http://linux.die.net/man/ , and
Linuxmanpages·com - http://linuxmanpages.com/

Time to re-evaluate my thinking and read more.
Thanks.

Thanks for the detailed explanation, uhelp
True, "The -n option to read will not detect the ENTER (newline) key" is not correct as shown by this command line experiment:

read -d '' -n1 -r -s
echo "'$REPLY'"

I can't find the text about cd's return value not being set correctly.

The "The cd command does not function as expected when presented with two forward slashes comment is questionable. Bash functions "as designed" in this regard but I would have designed it differently.

Originally Posted by Sector11 But on the command line I have always related the '&' to end commands or join commands.

The & used like that does "end a command". It puts the first command into the background then runs the second command. In the example given the command, gedit, works in the background so no problem. The same technique used with a command that does not work in the background -- such as vi -- would behave less usefully.

Safer to use ; to separate commands on the same line that are intended to be run in sequence (and subshells to run commands at the same time) because the result is more predictable.

"Join commands" could mean several different things ...

Originally Posted by catkin I can't find the text about cd's return value not being set correctly.

Well, I came across these issues some years ago.
It could be that this mistake has already been fixed.

I hat a short look at ABS to find one point to show here.

They also recommended that one should use only capitalized vars, which is quite stupid.
I did not see this recommendation today. May be this is fixed to, as I've seen some vars not capitalized.

Originally Posted by catkin The & used like that does "end a command". It puts the first command into the background then runs the second command. In the example given the command, gedit, works in the background so no problem. The same technique used with a command that does not work in the background -- such as vi -- would behave less usefully. Safer to use ; to separate commands on the same line that are intended to be run in sequence (and subshells to run commands at the same time) because the result is more predictable. "Join commands" could mean several different things ...

Oh I have to do more research. I tested:

nano;gedit;gedit -- didn't work - until I closed nano - then 2 gedit tabs
gedit;gedit;nano -- worked fine

I need more research on "symbols" just like Knightron was asking ....
I see & ; | && ;; || and combinations of them ... and more ... dizzy...
Back to the manuals
Thank you Catkin

I would say that the only real problem with the ABSG is that it gets updated rarely and sporadically, so changes and bugs that have been fixed are not always reflected accurately. It's one of those documents that long ago reached a relatively complete state, and now only gets attention when absolutely necessary.

I'll agree that it's generally not the first place to send a newbie, except in regards to specific topics like this one, but it remains one of the most useful and detailed guides to bash scripting, IMO.


@Sector11

The semicolon list operator is exactly equivalent to a newline as a command terminator. When the first command terminates, the second command is executed. The following two sets of commands are identical:

nano
gedit
nano

nano ; gedit ; nano

&& and || are conditional sequencers. && executes the second command only if the first one terminates successfully (gives an exit code of 0). This is particularly useful if the operation of the second command depends on what the first command does. Take this example:

cd dir ; rm -f *	#cd to dir, then run rm (unconditionally)
cd dir && rm -f *	#cd to dir, and if successful run rm (otherwise do nothing)

Without the conditional operator, if the cd command failed (e.g. dir doesn't exist), then you'd end up deleting everything in the directory you started in!


|| conversely executes the second command only if the first one exits unsuccessfully (exit code >0). This lets you specify an alternate command if something goes wrong with the first one.

cd dir || echo "Failed to change directories!"

And as explained, & is a terminator that forks the command off as a background sub-process, and then frees up the terminal in order to immediately execute the next command. It's quite appropriate to use it in the way you posted; catkin's caution was simply that you can't effectively background interactive commands that run directly in the terminal, like vim or nano. They simply get sent into the background in a suspended state and remain there until manually foregrounded or killed.

@ David the H.

Well, that explains things in a nice simple way. Thank you.
I found the same answers in the Bash "man"ual but your explanation is a lot clearer.