Hide

What's this?

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/

Get involved!

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.

Hide

Stay in the loop…

Follow the Tweets.

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

Subscribe to the feeds.

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:

Hide

News

2011-03-12 - Confoo 2011 presentation
Slides are available from the commandlinefu presentation at Confoo 2011: http://presentations.codeinthehole.com/confoo2011/
2011-01-04 - Moderation now required for new commands
To try and put and end to the spamming, new commands require moderation before they will appear on the site.
2010-12-27 - Apologies for not banning the trolls sooner
Have been away from the interwebs over Christmas. Will be more vigilant henceforth.
2010-09-24 - OAuth and pagination problems fixed
Apologies for the delay in getting Twitter's OAuth supported. Annoying pagination gremlin also fixed.
Hide

Tags

Hide

Functions

Generic shell function for modifying files in-place

Terminal - Generic shell function for modifying files in-place
inplace() { eval F=\"\$$#\"; "$@" > "$F".new && mv -f "$F".new "$F"; }
2010-04-09 11:36:31
User: inof
Functions: eval mv
1
Generic shell function for modifying files in-place

Some commands (such as sed and perl) have options to support in-place editing of files, but many commands do not. This shell function enables any command to change files in place. See the sample output for many examples.

The function uses plain sh syntax and works with any POSIX shell or derivative, including zsh and bash.

Alternatives

There is 1 alternative - vote for the best!

Terminal - Alternatives

Know a better way?

If you can do better, submit your command here.

What others think

Very nice. Of course, you can shorten it by a couple of chars :-)

inplace() { eval F=\"\$$#\"; "$@" > "$F".new && mv -f "$F"{.new,}; }
Comment by flatcap 237 weeks and 1 day ago

flatcap: If you shorten it that way, it doesn't work anymore in plain (POSIX) bourne shells (it still works with zsh and bash, though).

Personally I prefer it to be as portable as possible, even if it is two characters longer. That way I can easily share my collection of shell functions between different machines (BSD, Linux, Solaris).

If you absolutely need to make it shorter, you can omit several of the spaces that I left for better readability. That way you can save more than just two characters, and it's still portable. ;-)

Comment by inof 237 weeks and 1 day ago

FYI I'm working on an inplace script for coreutils that uses some of the techniques mentioned here:

http://www.pixelbeat.org/docs/unix_file_replacement.html

Comment by pixelbeat 236 weeks and 5 days ago

Ah-ha. Now I see why you downvoted my sedw function. I had not seen this one you wrote. You have some cool stuff; your shell skills are better than mine. But if we're playing keystroke golf, I think sedw 's/old/new/' beats inplace sed 's/old/new/' Beginner's luck. :)

Comment by argv 236 weeks ago

argv: I haven't voted on your sedw function (neither up nor down), if I recall correctly. But still, all the major BSDs have -i options for in-place editing, so there's no need in this case. Well, you could make an alias sedw="sed -i" if you want to save two keystrokes. ;-)

Comment by inof 235 weeks and 6 days ago

I just presumed it was you. I will find that guy who voted me down! ;)

NetBSD's sed does not have -i. This is why I made the sedi and sedw functions. Because the sed in NetBSD base does not have in-place editing.

I used aliases in the early days but now prefer functions. They allow more flexibility and can be used in scripts.

I like your approach to in-place editing; it's simple, verstile and portable.

I opted to use /tmp because that's what ed and the newer sed's do. They used /tmp for in-place editing. If your sed has an -i option, it's making a tmp file and then removing it.

I always have /tmp mounted as mfs or tmpfs.

Cheers.

Comment by argv 235 weeks and 6 days ago

argv: Using /tmp is a bad idea, actually, for security reasons. World-writable directories can be used for several kinds of attacks, for example symlink attacks. Even if you use '$$' there is a race condition that can be abused. Some systems provide tools like mktemp(1), but this is not portable.

Therefore I try to avoid using /tmp at all, especially on multi-use machines (shell boxes).

By the way, FreeBSD's sed doesn't use /tmp either. It creates a backup file in the same directory as the file being edited. I don't know what GNU sed does (I'm too lazy right now to log into a Linux machine for checking), but I guess it's also clever enough to not use /tmp.

Many programs recognize the environment variable TMPDIR, so I always set it to a directory that is not world-writable, like TMPDIR=$HOME/tmp (which is 0700, i.e. drwx------).

Comment by inof 235 weeks and 6 days ago

Thanks inof. If one is in a multi-user environment and truly paranoid about symlink-racing, then yes, avoid /tmp. And check all your applications as some of them may use it.

It was GNU sed I was thinking of that uses /tmp. I'm too lazy to install it or boot into a Linux to double check. I know ed uses /tmp. And vi uses /var/tmp for vi.recover, correct? I presumed sed's with in-place editing would use /tmp. As usual, BSD does the smart thing.

You have given me an idea. The next time I'm questioned why I don't use GNU sed, I can say I'm paranoid about race conditions.

Keep up the good work.

Comment by argv 235 weeks and 6 days ago

Your point of view

You must be signed in to comment.

Related sites and podcasts