What is the meaning of & at the end of a command?
I have a startup script line:
pyprogramm >> /dev/null 2>&1 &
Meanings:
>> /dev/null - redirect stdout to null device
2>&1 - redirect stderr to stdout (that is redirected to null device)
but what does the very last &
mean?
bash scripts stdout job-control
add a comment |
I have a startup script line:
pyprogramm >> /dev/null 2>&1 &
Meanings:
>> /dev/null - redirect stdout to null device
2>&1 - redirect stderr to stdout (that is redirected to null device)
but what does the very last &
mean?
bash scripts stdout job-control
add a comment |
I have a startup script line:
pyprogramm >> /dev/null 2>&1 &
Meanings:
>> /dev/null - redirect stdout to null device
2>&1 - redirect stderr to stdout (that is redirected to null device)
but what does the very last &
mean?
bash scripts stdout job-control
I have a startup script line:
pyprogramm >> /dev/null 2>&1 &
Meanings:
>> /dev/null - redirect stdout to null device
2>&1 - redirect stderr to stdout (that is redirected to null device)
but what does the very last &
mean?
bash scripts stdout job-control
bash scripts stdout job-control
edited yesterday
Zanna
50.2k13133241
50.2k13133241
asked 2 days ago
vico
1,15472345
1,15472345
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
What is the & terminator ?
The trailing &
operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:
Asynchronous Lists
If a command is terminated by the control operator
( '&' ), the shell shall execute the command
asynchronously in a subshell. This means that the shell shall not wait
for the command to finish before executing the next command.
The format for running a command in the background is:
command1 & [command2 & ... ]
The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.
From the definition you can see that &
also serves as command terminator for lists of commands, much like ;
does. In your specific example, pyprogramm >> /dev/null 2>&1 &
there is only one command in the list.
Sequential ; lists vs asynchronous & lists
More generally,
echo Hello ; echo World ;
and
echo Hello & echo World &
are two examples of lists terminated by the ;
and &
operators. One difference is that &
terminated list will have input connected to /dev/null
if job control is disabled:
If job control is disabled (see set, -m), the standard input for an
asynchronous list, before any explicit redirections are performed,
shall be considered to be assigned to a file that has the same
properties as /dev/null. This shall not happen if job control is
enabled. In all cases, explicit redirection of standard input shall
override this activity.
In sequential list, however, each command still has stdin
connected to terminal if there are no explicit redirections.
Note also, that from the definition we mentioned earlier, &
executes commands in subshell. By contrast, the ;
terminated list is executed in current shell. There's also difference in exit statuses. For &
the standard says:
The exit status of an asynchronous list shall be zero.
This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 &
running in background should have some way of indicating if it failed or not, however judging that you use 2>&1
you are hiding error output by redirecting, and you probably assume the script should not fail.
By contrast, ;
exit status is defined as:
The exit status of a sequential list shall be the exit status of the
last command in the list.
Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.
Side notes and additional reading
The fact that this is POSIX definition means that all Bourne-like shells, meaning
bash
,dash
, andksh
must support it.&
in redirection is different from&
as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?
In
bash
there is also|&
operator ( note no space between pipe and ampersand ). From bash manual:
If |& is used, command's standard error, in addition to its standard
output, is connected to command2's standard input through the pipe;
it is shorthand for 2>&1 |. This implicit redirection of the
standard error to the standard output is performed after any
redirections specified by the command.
2
What you say about&
hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from/dev/null
or equivalent.
– kasperd
yesterday
@kasperd That's an oopsie. Fixed. Thanks !
– Sergiy Kolodyazhnyy
yesterday
I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.
– kasperd
yesterday
@kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)
– Sergiy Kolodyazhnyy
yesterday
add a comment |
It means run the command in the background. The calling script continues rather than blocking until the called command completes.
add a comment |
&
this returns control of the script to the operating system but sent the response to the background not as nohup
that directly sends the entire execution
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1107124%2fwhat-is-the-meaning-of-at-the-end-of-a-command%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
What is the & terminator ?
The trailing &
operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:
Asynchronous Lists
If a command is terminated by the control operator
( '&' ), the shell shall execute the command
asynchronously in a subshell. This means that the shell shall not wait
for the command to finish before executing the next command.
The format for running a command in the background is:
command1 & [command2 & ... ]
The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.
From the definition you can see that &
also serves as command terminator for lists of commands, much like ;
does. In your specific example, pyprogramm >> /dev/null 2>&1 &
there is only one command in the list.
Sequential ; lists vs asynchronous & lists
More generally,
echo Hello ; echo World ;
and
echo Hello & echo World &
are two examples of lists terminated by the ;
and &
operators. One difference is that &
terminated list will have input connected to /dev/null
if job control is disabled:
If job control is disabled (see set, -m), the standard input for an
asynchronous list, before any explicit redirections are performed,
shall be considered to be assigned to a file that has the same
properties as /dev/null. This shall not happen if job control is
enabled. In all cases, explicit redirection of standard input shall
override this activity.
In sequential list, however, each command still has stdin
connected to terminal if there are no explicit redirections.
Note also, that from the definition we mentioned earlier, &
executes commands in subshell. By contrast, the ;
terminated list is executed in current shell. There's also difference in exit statuses. For &
the standard says:
The exit status of an asynchronous list shall be zero.
This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 &
running in background should have some way of indicating if it failed or not, however judging that you use 2>&1
you are hiding error output by redirecting, and you probably assume the script should not fail.
By contrast, ;
exit status is defined as:
The exit status of a sequential list shall be the exit status of the
last command in the list.
Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.
Side notes and additional reading
The fact that this is POSIX definition means that all Bourne-like shells, meaning
bash
,dash
, andksh
must support it.&
in redirection is different from&
as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?
In
bash
there is also|&
operator ( note no space between pipe and ampersand ). From bash manual:
If |& is used, command's standard error, in addition to its standard
output, is connected to command2's standard input through the pipe;
it is shorthand for 2>&1 |. This implicit redirection of the
standard error to the standard output is performed after any
redirections specified by the command.
2
What you say about&
hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from/dev/null
or equivalent.
– kasperd
yesterday
@kasperd That's an oopsie. Fixed. Thanks !
– Sergiy Kolodyazhnyy
yesterday
I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.
– kasperd
yesterday
@kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)
– Sergiy Kolodyazhnyy
yesterday
add a comment |
What is the & terminator ?
The trailing &
operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:
Asynchronous Lists
If a command is terminated by the control operator
( '&' ), the shell shall execute the command
asynchronously in a subshell. This means that the shell shall not wait
for the command to finish before executing the next command.
The format for running a command in the background is:
command1 & [command2 & ... ]
The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.
From the definition you can see that &
also serves as command terminator for lists of commands, much like ;
does. In your specific example, pyprogramm >> /dev/null 2>&1 &
there is only one command in the list.
Sequential ; lists vs asynchronous & lists
More generally,
echo Hello ; echo World ;
and
echo Hello & echo World &
are two examples of lists terminated by the ;
and &
operators. One difference is that &
terminated list will have input connected to /dev/null
if job control is disabled:
If job control is disabled (see set, -m), the standard input for an
asynchronous list, before any explicit redirections are performed,
shall be considered to be assigned to a file that has the same
properties as /dev/null. This shall not happen if job control is
enabled. In all cases, explicit redirection of standard input shall
override this activity.
In sequential list, however, each command still has stdin
connected to terminal if there are no explicit redirections.
Note also, that from the definition we mentioned earlier, &
executes commands in subshell. By contrast, the ;
terminated list is executed in current shell. There's also difference in exit statuses. For &
the standard says:
The exit status of an asynchronous list shall be zero.
This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 &
running in background should have some way of indicating if it failed or not, however judging that you use 2>&1
you are hiding error output by redirecting, and you probably assume the script should not fail.
By contrast, ;
exit status is defined as:
The exit status of a sequential list shall be the exit status of the
last command in the list.
Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.
Side notes and additional reading
The fact that this is POSIX definition means that all Bourne-like shells, meaning
bash
,dash
, andksh
must support it.&
in redirection is different from&
as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?
In
bash
there is also|&
operator ( note no space between pipe and ampersand ). From bash manual:
If |& is used, command's standard error, in addition to its standard
output, is connected to command2's standard input through the pipe;
it is shorthand for 2>&1 |. This implicit redirection of the
standard error to the standard output is performed after any
redirections specified by the command.
2
What you say about&
hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from/dev/null
or equivalent.
– kasperd
yesterday
@kasperd That's an oopsie. Fixed. Thanks !
– Sergiy Kolodyazhnyy
yesterday
I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.
– kasperd
yesterday
@kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)
– Sergiy Kolodyazhnyy
yesterday
add a comment |
What is the & terminator ?
The trailing &
operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:
Asynchronous Lists
If a command is terminated by the control operator
( '&' ), the shell shall execute the command
asynchronously in a subshell. This means that the shell shall not wait
for the command to finish before executing the next command.
The format for running a command in the background is:
command1 & [command2 & ... ]
The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.
From the definition you can see that &
also serves as command terminator for lists of commands, much like ;
does. In your specific example, pyprogramm >> /dev/null 2>&1 &
there is only one command in the list.
Sequential ; lists vs asynchronous & lists
More generally,
echo Hello ; echo World ;
and
echo Hello & echo World &
are two examples of lists terminated by the ;
and &
operators. One difference is that &
terminated list will have input connected to /dev/null
if job control is disabled:
If job control is disabled (see set, -m), the standard input for an
asynchronous list, before any explicit redirections are performed,
shall be considered to be assigned to a file that has the same
properties as /dev/null. This shall not happen if job control is
enabled. In all cases, explicit redirection of standard input shall
override this activity.
In sequential list, however, each command still has stdin
connected to terminal if there are no explicit redirections.
Note also, that from the definition we mentioned earlier, &
executes commands in subshell. By contrast, the ;
terminated list is executed in current shell. There's also difference in exit statuses. For &
the standard says:
The exit status of an asynchronous list shall be zero.
This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 &
running in background should have some way of indicating if it failed or not, however judging that you use 2>&1
you are hiding error output by redirecting, and you probably assume the script should not fail.
By contrast, ;
exit status is defined as:
The exit status of a sequential list shall be the exit status of the
last command in the list.
Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.
Side notes and additional reading
The fact that this is POSIX definition means that all Bourne-like shells, meaning
bash
,dash
, andksh
must support it.&
in redirection is different from&
as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?
In
bash
there is also|&
operator ( note no space between pipe and ampersand ). From bash manual:
If |& is used, command's standard error, in addition to its standard
output, is connected to command2's standard input through the pipe;
it is shorthand for 2>&1 |. This implicit redirection of the
standard error to the standard output is performed after any
redirections specified by the command.
What is the & terminator ?
The trailing &
operator at the end of a command is used to put commands into background. This is actually a standard syntax specified by POSIX standard:
Asynchronous Lists
If a command is terminated by the control operator
( '&' ), the shell shall execute the command
asynchronously in a subshell. This means that the shell shall not wait
for the command to finish before executing the next command.
The format for running a command in the background is:
command1 & [command2 & ... ]
The purpose of backgrounding commands is to run a command without the main shell in script or interactive shell waiting for command, which would block execution of other commands and make an inconvenience for the user to wait. This is handy for starting long-running commands but you need to continue work in the current shell. As you can guess, this originated from the time where there were no multi-tab terminal emulators, but terminals were actual physical hardware connected to a computer itself.
From the definition you can see that &
also serves as command terminator for lists of commands, much like ;
does. In your specific example, pyprogramm >> /dev/null 2>&1 &
there is only one command in the list.
Sequential ; lists vs asynchronous & lists
More generally,
echo Hello ; echo World ;
and
echo Hello & echo World &
are two examples of lists terminated by the ;
and &
operators. One difference is that &
terminated list will have input connected to /dev/null
if job control is disabled:
If job control is disabled (see set, -m), the standard input for an
asynchronous list, before any explicit redirections are performed,
shall be considered to be assigned to a file that has the same
properties as /dev/null. This shall not happen if job control is
enabled. In all cases, explicit redirection of standard input shall
override this activity.
In sequential list, however, each command still has stdin
connected to terminal if there are no explicit redirections.
Note also, that from the definition we mentioned earlier, &
executes commands in subshell. By contrast, the ;
terminated list is executed in current shell. There's also difference in exit statuses. For &
the standard says:
The exit status of an asynchronous list shall be zero.
This is significant when you want to put multiple commands in background. When you write a script or command you will have to chose commands for which you don't care if they failed or not, or you will have to find a way to handle the non-zero ( error ) exit status. In your specific example, pyprogramm >> /dev/null 2>&1 &
running in background should have some way of indicating if it failed or not, however judging that you use 2>&1
you are hiding error output by redirecting, and you probably assume the script should not fail.
By contrast, ;
exit status is defined as:
The exit status of a sequential list shall be the exit status of the
last command in the list.
Again, this has implications on how you write a sequential list of commands in command-line and how you want things to be handled if some of the commands in the list failed.
Side notes and additional reading
The fact that this is POSIX definition means that all Bourne-like shells, meaning
bash
,dash
, andksh
must support it.&
in redirection is different from&
as command terminator. It means duplicating (copying) the file-descriptor object. See What does & mean exactly in output redirection?
In
bash
there is also|&
operator ( note no space between pipe and ampersand ). From bash manual:
If |& is used, command's standard error, in addition to its standard
output, is connected to command2's standard input through the pipe;
it is shorthand for 2>&1 |. This implicit redirection of the
standard error to the standard output is performed after any
redirections specified by the command.
edited yesterday
answered 2 days ago
Sergiy Kolodyazhnyy
70.1k9144307
70.1k9144307
2
What you say about&
hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from/dev/null
or equivalent.
– kasperd
yesterday
@kasperd That's an oopsie. Fixed. Thanks !
– Sergiy Kolodyazhnyy
yesterday
I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.
– kasperd
yesterday
@kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)
– Sergiy Kolodyazhnyy
yesterday
add a comment |
2
What you say about&
hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from/dev/null
or equivalent.
– kasperd
yesterday
@kasperd That's an oopsie. Fixed. Thanks !
– Sergiy Kolodyazhnyy
yesterday
I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.
– kasperd
yesterday
@kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)
– Sergiy Kolodyazhnyy
yesterday
2
2
What you say about
&
hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null
or equivalent.– kasperd
yesterday
What you say about
&
hiding output does not sound correct. The paragraph from the standard which you are quoting speaks of input, not output. The reason for the distinction between job control being enabled or not is that a background process attempting to read from the tty will get suspended. At that point you need to use job control to put it in the foreground to provide the input it is waiting for. All of that can't be done without job control and thus if job control is disabled the stdin needs to be redirected from /dev/null
or equivalent.– kasperd
yesterday
@kasperd That's an oopsie. Fixed. Thanks !
– Sergiy Kolodyazhnyy
yesterday
@kasperd That's an oopsie. Fixed. Thanks !
– Sergiy Kolodyazhnyy
yesterday
I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.
– kasperd
yesterday
I spotted a mistake in your edit as well. In one place you wrote enabled where you should have written disabled.
– kasperd
yesterday
@kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)
– Sergiy Kolodyazhnyy
yesterday
@kasperd Yeah, I was just re-reading the POSIX page when I noticed that as well. Already fixed. Let me know if anything else needs editing. Thanks :)
– Sergiy Kolodyazhnyy
yesterday
add a comment |
It means run the command in the background. The calling script continues rather than blocking until the called command completes.
add a comment |
It means run the command in the background. The calling script continues rather than blocking until the called command completes.
add a comment |
It means run the command in the background. The calling script continues rather than blocking until the called command completes.
It means run the command in the background. The calling script continues rather than blocking until the called command completes.
answered 2 days ago
Robert Longson
259410
259410
add a comment |
add a comment |
&
this returns control of the script to the operating system but sent the response to the background not as nohup
that directly sends the entire execution
New contributor
add a comment |
&
this returns control of the script to the operating system but sent the response to the background not as nohup
that directly sends the entire execution
New contributor
add a comment |
&
this returns control of the script to the operating system but sent the response to the background not as nohup
that directly sends the entire execution
New contributor
&
this returns control of the script to the operating system but sent the response to the background not as nohup
that directly sends the entire execution
New contributor
New contributor
answered yesterday
Bryro
101
101
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1107124%2fwhat-is-the-meaning-of-at-the-end-of-a-command%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown