When creating an empty file, why might one prefer 'touch file' over ': >> file'?

Question

Never realized that you could do this until just now:

: >> file

It seems to be functionally similar to:

touch file

Is there a reason why most resources seem to prefer touch over this shell builtin?

The short form may be shell related, while touch is a standalone command. Hence the short form depends on which shell you use (and people do have strong preferences in this area) as maybe not all of them provide the shortcut. touch being standalone will work the same way whatever should you use. — Patrick Mevzek, May 25 '18 at 18:00
Related What is the difference between touch file and > file on AU. — αғsнιη, May 25 '18 at 18:01
The first example should be edited to : >> file or even >> file, so that they have the same effect, i.e. NOT destroying the contents of file. — user000001, May 26 '18 at 08:51
touch primarily updates the mtime. It does not empty an existing file unlike >. — rexkogitans, May 26 '18 at 18:36
Not exactly the same, but related, and has good info: Difference between cat and '>' to zero out a file — phemmer, May 27 '18 at 07:27
Neither command "creates an empty file"; they only have this result if the file does not yet exist. To guarantee an empty file, you need > file. — alexis, May 27 '18 at 11:00

score 48 · Accepted Answer · edited May 27 '18 at 01:12

You don't even need to use :; you can just > file (at least in bash; other shells may behave differently).

In practical terms, there is no real difference here (though the minuscule overhead of calling out to /bin/touch is a thing).

touch, however, can also be used to modify the timestamps on a file that already exists without changing or erasing the contents; further, > file will blow out any file that already exists. This can be worked around by instead using >> file.

One other difference with touch is that you can have it create (or update the timestamp on) multiple files at once (e.g. touch foo bar baz quux) with a more succinct syntax than with redirection, where each file needs its own redirection (e.g. >foo >bar >baz >quux).

Using touch:

$ touch foo; stat -x foo; sleep 2; touch foo; stat -x foo
  File: "foo"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (991148597/redacted)  Gid: (1640268302/redacted)
Device: 1,5   Inode: 8597208698    Links: 1
Access: Fri May 25 10:55:19 2018
Modify: Fri May 25 10:55:19 2018
Change: Fri May 25 10:55:19 2018
  File: "foo"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (991148597/redacted)  Gid: (1640268302/redacted)
Device: 1,5   Inode: 8597208698    Links: 1
Access: Fri May 25 10:55:21 2018
Modify: Fri May 25 10:55:21 2018
Change: Fri May 25 10:55:21 2018

Using redirection:

$ > foo; stat -x foo; sleep 2; >> foo; stat -x foo
  File: "foo"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (991148597/redacted)  Gid: (1640268302/redacted)
Device: 1,5   Inode: 8597208698    Links: 1
Access: Fri May 25 10:55:21 2018
Modify: Fri May 25 10:56:25 2018
Change: Fri May 25 10:56:25 2018
  File: "foo"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (991148597/redacted)  Gid: (1640268302/redacted)
Device: 1,5   Inode: 8597208698    Links: 1
Access: Fri May 25 10:55:21 2018
Modify: Fri May 25 10:56:25 2018
Change: Fri May 25 10:56:25 2018

It seems like >> file will not update the modify time. Not what OP is looking for but just wanted to point out it doesn't seem to be a complete alternative to touch. — jesse_b, May 25 '18 at 17:53
Since the question doesn't specify a particular shell. It might be good to point out that > file in zsh is equivalent to cat > file, not : > file. — JoL, May 25 '18 at 20:59
Also, tcsh allows : > file, but errs on > file. Maybe the equivalence of > file to : > file is limited to the bourne shell and bash? — JoL, May 25 '18 at 21:09
+1 for thoroughness, however note that on several mainstream shells (I would even guess all or most shells because the most simple implementation would naturally cause this to work as a side-effect), you can touch multiple files using shell redirection: : >foo >bar or : >>foo >>bar will touch both foo and bar. — mtraceur, May 25 '18 at 21:33
Only to be pedantic because of the context of the actual question here, but : >foo >bar will not touch the files; it will redirect the (null) output of : into the files. touch would touch the files. (: — DopeGhoti, May 29 '18 at 15:14

score 32 · Answer 2 · edited May 27 '18 at 01:10

32

Because you can touch multiple files at one go without typing any extra special characters. That includes stuff like brace expansion, e.g. touch file{1,2,3,4}.

Another issue is that when you're writing a tutorial, it's rather important to realize that your readers probably aren't very well-versed in the subject. A simple command can be much more understandable than some weird-looking combination of non-letter characters. I would expect there are a number of casual shell users who don't know what : is, for the simple reason that it doesn't really do anything. Similarly for a plain > foo without a command: even if you know what a redirection is, a redirection without a source may be unintuitive.

Also, here on unix.se we often write command samples with a leading dollar sign to indicate the prompt. Special characters at the start of the line might be confused with that. (Note that there are systems and shells that use > as part of the default prompt.)

edited May 27 '18 at 01:10

Jeff Schaller

67,283
35
116
255

answered May 25 '18 at 18:02

ilkkachu

138,973

4

And if the command is not completely understood, there's always "man touch". I doubt that "man : > file" would return anything useful :-) Also WRT prompts, some (perhaps most) allow you to set the prompt to be anything you like. Mine shows system name (because I use a lot of remote xterms) and current directory, and is set to different colors for different systems. – jamesqf May 25 '18 at 18:44
1

@jamesqf, yep. Now, of course there's also help : or whatever your shell has for documentation. But that requires recognizing : as a command in itself, remembering that not everything has a man page, and finally, being able to find : in the documentation. The last part can be quite difficult. :D – ilkkachu May 25 '18 at 18:51
@jamesqf, and yeah, I mostly meant the final character of the default prompt. – ilkkachu May 25 '18 at 18:52
1

+1 for pointing out the intuition and not-being-an-obscure-construct aspects. – mtraceur May 25 '18 at 21:38
@ilkkachu: Yeah. Finding colons in documentation isn't that difficult: finding the one that's not just punctuation is a different matter :-) – jamesqf May 26 '18 at 04:41
@jamesqf actually it's very easy once you know that commands are usually listed in manual pages with several spaces before them, so e.g. : (two spaces and a colon) will immediately match the relevant description in bash(1). – Ruslan May 28 '18 at 06:37

score 18 · Answer 3 · answered May 26 '18 at 08:32

Well, for me, the primary reason is readability. With touch file you know what's going on, even someone not quite educated in shell scripting knows what's going on. And if not, it's easy to do man touch and see this:

A FILE argument that does not exist is created empty

With the cryptic stuff such as : and >, it's more difficult to know what's going on, and as there's no real advantage, there's no need to use that.

score 6 · Answer 4 · answered May 27 '18 at 09:27

Imagine that you are in search of one of your old shell scripts of which you only remember that some marker file in /tmp is being created. It's easy to grep all your *.sh files for the word "touch". Grepping for a colon instead will yield many false positives if you don't know which exact filename to search for.

When creating an empty file, why might one prefer 'touch file' over ': >> file'?

4 Answers4