Skip to main content
40 events
when toggle format what by license comment
Oct 25, 2023 at 9:27 history edited Kusalananda CC BY-SA 4.0
fix link
Aug 11, 2021 at 8:20 history edited Stéphane Chazelas CC BY-SA 4.0
added 232 characters in body
Aug 11, 2021 at 7:59 history edited Kusalananda CC BY-SA 4.0
added 102 characters in body
May 11, 2020 at 6:41 history edited Kusalananda CC BY-SA 4.0
added 18 characters in body
May 11, 2020 at 6:33 history edited Kusalananda CC BY-SA 4.0
added 184 characters in body
Sep 3, 2018 at 5:18 history edited Kusalananda CC BY-SA 4.0
added 14 characters in body
Jun 9, 2018 at 9:39 history edited Kusalananda CC BY-SA 4.0
added 9 characters in body
Apr 20, 2018 at 20:46 history edited Kusalananda CC BY-SA 3.0
added 323 characters in body
Aug 27, 2017 at 9:50 history edited Kusalananda CC BY-SA 3.0
added 100 characters in body
Apr 13, 2017 at 12:36 history edited CommunityBot
replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
Apr 7, 2017 at 17:02 history edited Kusalananda CC BY-SA 3.0
edited body
Apr 7, 2017 at 14:33 history edited Toby Speight CC BY-SA 3.0
Use real superscript numbers
Apr 7, 2017 at 8:33 history edited Kusalananda CC BY-SA 3.0
added 49 characters in body
Apr 7, 2017 at 8:24 history edited Kusalananda CC BY-SA 3.0
added 296 characters in body
Apr 7, 2017 at 8:19 comment added Stéphane Chazelas Something to be aware of: when linking to POSIX with HTML fragments, it's better to specify the exact edition (like pubs.opengroup.org/onlinepubs/9699919799.2016edition) as fragments have been known to change between editions of a same revision of the spec (a lot of links in answers on this site including of mine are now wrong as the fragments point in the wrong place after the 2016 edition has been released).
Apr 7, 2017 at 8:14 history edited muru CC BY-SA 3.0
named the links
Apr 7, 2017 at 8:09 history edited Kusalananda CC BY-SA 3.0
added 719 characters in body
Apr 6, 2017 at 16:59 comment added Sergiy Kolodyazhnyy Yup, good answer, and in fact as far as bash specifically is concerned, the manual states in Redirection section "redirection operators may precede or appear anywhere within a simple command or may follow a command."
Apr 6, 2017 at 9:09 comment added Muzer @WumpusQ.Wumbley I've occasionally had cases where I've been running commands like some -really -long -command -with -lots -of -options -oneOptionIWantToChange > some/annoyingly/long/path 2> some/different/annoyingly/long/path. Putting the redirections at the beginning would make the option I want to change in a more convenient place. This is obviously quite a rare case though!
Apr 6, 2017 at 1:11 comment added muru @setht unix.stackexchange.com/a/186126/70524
Apr 5, 2017 at 18:30 history edited Kusalananda CC BY-SA 3.0
edited body
Apr 5, 2017 at 17:30 history edited Kusalananda CC BY-SA 3.0
added 14 characters in body
Apr 5, 2017 at 14:59 comment added Kusalananda @Wossname BTW, sudo grep something file1 | sudo tee file2 >/dev/null will solve the permission issue I mentioned.
Apr 5, 2017 at 14:57 comment added user155838 @Kusalananda, good points.
Apr 5, 2017 at 14:54 comment added Kusalananda @Wossname Whether the shell or the utility opens a file is less of a performance issue in general. Repeatedly appending to an output file is slow if it requires the shell (or the utility) to re-open the file for each additional bit of data. In those cases it's better to open the file for appending with >> once and then iterate over the utility. This is most often done by placing >>outfile after the done in the loop, rather than with the invocation of the utility. But, as I said, the difference between letting the utility or the shell open a file is, I assume, minimal.
Apr 5, 2017 at 14:47 comment added Kusalananda @Wossname The most common issue with permissions and redirections is probably conjunction with sudo, e.g. sudo grep something file1 >file2 when in a directory only writable by root. The redirection fails even before the sudo command is invoked.
Apr 5, 2017 at 14:42 comment added user41515 @Steve The freedom to move redirections around can be used to make some commands clearer, like a pipeline with input redirection at the beginning <in foo | bar >out puts everything in logical order. I'm also fond if echo >&2 Something bad happened for error output from shell scripts. But >out <in cat is just obfuscation
Apr 5, 2017 at 14:42 comment added Kusalananda @Steve there is no advantage. I've come across one person in this forum who thought that writing <file1 cat >file2 was more intuitive than cat <file1 >file2 (or any other permutation).
Apr 5, 2017 at 14:39 comment added user155838 Nicely explained. I wonder if having the shell perform the initial file openings on behalf of the named command has some performance benefits (or detriments) in some situations. Might it also have implications for access permissions (consider a setuid executable being run by a user logged in with restricted permissions). Great answer +1.
Apr 5, 2017 at 14:39 comment added Steve Is there some advantage to the form used by the OP? Or is this just someone being fancy?
Apr 5, 2017 at 14:01 history edited Kusalananda CC BY-SA 3.0
added 4 characters in body
Apr 5, 2017 at 13:53 history edited Kusalananda CC BY-SA 3.0
added 4 characters in body
Apr 5, 2017 at 13:47 history edited Kusalananda CC BY-SA 3.0
added 38 characters in body
Apr 5, 2017 at 13:45 history edited dr_ CC BY-SA 3.0
Added link to useful question
Apr 5, 2017 at 13:42 history edited Kusalananda CC BY-SA 3.0
edited body
Apr 5, 2017 at 13:16 history edited Kusalananda CC BY-SA 3.0
added 210 characters in body
Apr 5, 2017 at 12:58 vote accept shaqed
Apr 5, 2017 at 12:58 history edited Kusalananda CC BY-SA 3.0
added 222 characters in body
Apr 5, 2017 at 12:52 history edited Kusalananda CC BY-SA 3.0
added 222 characters in body
Apr 5, 2017 at 12:47 history answered Kusalananda CC BY-SA 3.0