what the fuc>|?
December 13, 2005 8:52 AM Subscribe
What does >| do in a shell script?
In the course of tracking down a video driver issue on a new install of Ubuntu Linux, I came across this solution to the problem I was having, which involves making the following shell script run during init:
Initially I thought the >| construct must just be a typo for >, so I deleted the | - and found that the script failed, complaining about read-only filesystems. So I put both the >| things back in and it works.
In many years of shell scripting I have never seen this construct used or documented. What exactly does it do? And which manual says so?
In the course of tracking down a video driver issue on a new install of Ubuntu Linux, I came across this solution to the problem I was having, which involves making the following shell script run during init:
#!/bin/sh
# Fix wrong MTRR setting
echo "disable=0" >| /proc/mtrr
echo "base=0x0 size=0x40000000 type=write-back" >| /proc/mtrr
Initially I thought the >| construct must just be a typo for >, so I deleted the | - and found that the script failed, complaining about read-only filesystems. So I put both the >| things back in and it works.
In many years of shell scripting I have never seen this construct used or documented. What exactly does it do? And which manual says so?
Best answer: From man bash: "If the redirection operator is >, and the noclobber option to the set builtin has been enabled, the redirection will fail if the file whose name results from the expansion of word exists and is a regular file. If the redirection operator is >|, or the redirection operator is > and the noclobber option to the set builtin command is not enabled, the redirection is attempted even if the file named by word exists."
(noclobber can also be set by adding -C to the bash command line)
posted by Plutor at 9:05 AM on December 13, 2005
(noclobber can also be set by adding -C to the bash command line)
posted by Plutor at 9:05 AM on December 13, 2005
>> will always append, no matter what the setting of noclobber.
If noclobber is set and the file exists, > will fail (do nothing) and >| will succeed (and overwrite the file).
posted by Plutor at 9:07 AM on December 13, 2005
If noclobber is set and the file exists, > will fail (do nothing) and >| will succeed (and overwrite the file).
posted by Plutor at 9:07 AM on December 13, 2005
Too late to provide the answer, so I'll just say: cute title.
posted by blue mustard at 9:08 AM on December 13, 2005
posted by blue mustard at 9:08 AM on December 13, 2005
I thought that was >>
posted by odinsdream at 9:05 AM PST on December 13 [!]
That appends to file.
posted by The Jesse Helms at 10:50 AM on December 13, 2005
posted by odinsdream at 9:05 AM PST on December 13 [!]
That appends to file.
posted by The Jesse Helms at 10:50 AM on December 13, 2005
Response by poster: Huh. That's what I get for typing />| at the man prompt instead of />\|... live and learn. Thanks, kindall; thanks, Plutor.
posted by flabdablet at 12:08 AM on December 14, 2005
posted by flabdablet at 12:08 AM on December 14, 2005
Response by poster: Also, if anybody cares: turns out the "read-only file system" error had nothing to do with the difference between > and >|. Correlation really isn't the same thing as causality.
The script in question gets run by the Ubuntu init system, and I'd set up a symlink to it at /etc/rcS.d/S02fix_mtrr as instructed. Trouble is that the instructions were written for one of the other Debians; in the Ubuntu variant, /etc/rcS.d/S02mountvirtfs also exists. This creates a race that mountvirtfs only wins some of the time - meaning that the /proc special file system is sometimes not mounted when the fix_mtrr script tries to write to it, meaning that fix_mtrr sometimes tries to write to regular file /proc/mtrr in the root file system which, at that point, is indeed mounted read-only.
After moving the symlink to /etc/rcS.d/S03fix_mtrr, it works every time.
posted by flabdablet at 4:05 AM on December 14, 2005
The script in question gets run by the Ubuntu init system, and I'd set up a symlink to it at /etc/rcS.d/S02fix_mtrr as instructed. Trouble is that the instructions were written for one of the other Debians; in the Ubuntu variant, /etc/rcS.d/S02mountvirtfs also exists. This creates a race that mountvirtfs only wins some of the time - meaning that the /proc special file system is sometimes not mounted when the fix_mtrr script tries to write to it, meaning that fix_mtrr sometimes tries to write to regular file /proc/mtrr in the root file system which, at that point, is indeed mounted read-only.
After moving the symlink to /etc/rcS.d/S03fix_mtrr, it works every time.
posted by flabdablet at 4:05 AM on December 14, 2005
This thread is closed to new comments.
As for where this is documented, try man bash.
posted by kindall at 9:03 AM on December 13, 2005