commandlinefu.com is the place to record those command-line gems that you return to again and again.
Delete that bloated snippets file you've been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.
If you have a new feature suggestion or find a bug, please get in touch via http://commandlinefu.uservoice.com/
You can sign-in using OpenID credentials, or register a traditional username and password.
First-time OpenID users will be automatically assigned a username which can be changed after signing in.
Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.
» http://twitter.com/commandlinefu
» http://twitter.com/commandlinefu3
» http://twitter.com/commandlinefu10
Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):
Subscribe to the feed for:
Test scenario:
* Open xterm (or konsole, ...)
* Start xeyes with: ( xeyes & )
* Close the xterminal
The xeyes process should be still running.
There are 3 alternatives - vote for the best!
If you can do better, submit your command here.
You must be signed in to comment.
{ list; } &
{ list; } & doesn't work here.
I started xeyes this way. After closing the terminal, xeyes was terminated.
This doesn't happen, if you start it with ( xeyes & ).
Wow. How does it work? Does it fork shell one additional time?
Yes, you are right.
But if you are running a script which consist of { list; } &
it acts the same.
lockie, the following is taken from ``man bash' ' :
(list) list is executed in a subshell environment.
Just to add my $0.02, it starts the process in the background in its own sub-shell. So it won't die if the spawning shell of the sub-shell is terminated.
I always used to hup my commands to keep them alive even if the parent dies. However, I like this better! :)
wouldn't
command & exitalso work?
What's wrong with
nohup xeyes&nice one! :) will definitely put to use
Zsh has an even nicer way to do the same
command &!nohup leaves all those annoying "nohup.out" files that I don't really care for. they pollute my filesystem if left unchecked