8 ms·

Because for some bizarre reason, "cut" doesn't ship with any decent column selection logic that is the equivalent of awk's $1, $2, etc., even in 2020. That's l

• pizza234 7y ago
  > I don't know of any easier equivalent of "awk '{ print $2 }'" for what it does. I'm not sure if you refer spefically to cut, but Perl has something similar and approximaly terse: > echo 'a b c' | perl -lane 'print $F[1]' Also, Perl can slice arrays, which is something that I really miss in Awk.
  • jerf 7y ago
    That is closest, yes. I'd say clearly a couple more things to remember, but if I can get it into my fingers will be just as fluid. Awk's invocation has its own issues around needing to escape the things the shell thinks it owns, too, not that it's at all unique about that.
  • 0xff00ffee 7y ago
    PERL is bloatware by comparison and less likely to be installed on distros than AWK. (e.g, embedded or slim distros. that's why you rarely see nonstandard /bin execs in shell scripts).
    • sigjuice 7y ago
      The awk on an embedded system is most likely a non-mainstream awk implementation with fewer or different features.
      • 0xff00ffee 7y ago
        Proof? Or are you just guessing?
        • nrclark 7y ago
          Can confirm. GNU awk is GPLv3, which means it can't be legally included on any system that prevents a user from modifying the installed firmware. This is a result of GPLv3's "Installation Instructions" requirement. Every commercial embedded Linux product that I've seen uses Busybox (or maybe Toybox) to provide the coreutils. If awk is available on a system like that, it's almost certainly Busybox awk. And Busybox awk is fine for a lot of things. But it's definitely different than GNU awk, and it's not 100% compatible in all cases.
          • 0xff00ffee 7y ago
            Thanks. I forgot GPL is the touch of death in many cases due to how it infects entire codebases. I can't edit my OP but I'm already downvoted so that will suffice.
            • nrclark 7y ago
              Specifically GPLv3 is the sticking point - not the GPL in general. GPLv2 is a great license, and I use it for a lot of tools that I write. That's the license that the Linux kernel uses. GPLv3 (which was written in 2007) has much tougher restrictions. It's the license for most of the GNU packages now, and GPLv3 packages are impractical to include in any firmware that also comes with secret sauce. So most of us in the embedded space have ditched the GNU tools in our production firmware (even if they're still used to _compile_ that firmware).
              • GhettoMaestro 7y ago
                Thanks for reminding me once again than Stallman is a narrow -minded dipshit.
              • cyphar 7y ago
                That's not an entirely accurate understanding of the GPLv3 "anti-tivoisation" restrictions. The restrictions boil down to "if you distribute hardware that has GPLv3 code on it, you must provide the source code (as with GPLv2) and a way for users to replace the GPLv3 code -- but only if it is possible for the vendor to do such a replacement". There's no requirement to relicense other code to GPLv3 -- if there were then GPLv3 wouldn't be an OSI-approved license. It should be noted that GPLv2 actually had a (much weaker) version of the same restriction: > For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. [emphasis added] (Scripts in this context doesn't mean "shell scripts" necessarily, but more like instructions -- like the script of a play.) So it's not really a surprise that (when the above clause was found to not solve the problem of unmodifiable GPL code) the restrictions were expanded. The GPLv3 also has a bunch of other improvements (such as better ways of resolving accidental infringement, and a patents clause to make it compatible with Apache-2.0).
    • svnpenn 7y ago
      > PERL is bloatware never heard that before
      • Annatar 7y ago
        There is a first time for everything, and it's true: Perl is mega bloatware, especially when compared to AWK.
    • 7thaccount 7y ago
      Perl used to be part of most distros, but I think favor shifted to Python a few years ago. I wouldn't call it bloat, but yes it is much bigger. At the time you had C (really fast, but cumbersome) and Awk/Bash (good prototyping tools, but not good for large codebases). Perl was the perfect answer to something that is fairly fast, relatively easy to develop in, and easier to write full-sized codebases
      • gbacon 7y ago
        Larry Wall referred to the old dichotomy of the “manipulexity” of C for reaching into low-level system details versus the “whipuptitude” of shell, awk, sed, and friends. He targeted Perl for the sweet spot in the unfilled gap between them.
        • 7thaccount 7y ago
          Thanks for explaining it better than me!
    • shaklee3 7y ago
      Unfortunately, for large files perl is significantly faster than awk. I was working on some very large files doing some splitting, and perl was over an order of magnitude faster.
      • gbacon 7y ago
        A tool that is stable, well supported, has outstanding documentation, thoroughly tested, won’t capriciously break your code, and outperforms the rest of the pack is not the unfortunate case.
      • shaklee3 7y ago
        To be more clear, the unfortunately part was due to the title of this article. I think awk is great, but if you know perl well enough it can easily replace it and be much more versatile
    • gbacon 7y ago
      Do you have data on the relative sizes of the Perl and awk install bases? Perl is the language, and perl is the implementation. Spelling it with ALL CAPS announces that someone knows little about the language.
    • pizza234 7y ago
      Even assuming the odd "bloatware" characterization, this is irrelevant. From the article's point of view of "simple tasks", bloat or not doesn't matter; what matter is the language syntax and features used to accomplish a task (and I'd add consistency across platforms). Regarding slim/embedded distros, it depends on the use cases, and the definition of "slim". It's hard to make broad statements on their prevalence, and regardless, I've never stated that one should use Perl instead and/or that it's "better"; only stated that the option it gives is a valid one.
  • kragen 7y ago
    If you're golfing, there's also echo a b c | perl -pale '$_=$F[1]'
  • Annatar 7y ago
    Perl stole array slicing from AWK's split() function... which slices arrays.
• samatman 7y ago
  The reason isn't that bizarre; it's a POSIX utility and must conform to the specification, which you can read here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
  • clarry 7y ago
    Does POSIX forbid extensions? That would be terrible.
    • samatman 7y ago
      Well... no, it doesn't, obviously, we can take a quick look at gawk to confirm this. But, just as we can't say "awk offers the -b flag to process characters as bytes", we can't really say that cut offers any extensions not defined in the standard. An implementation could, sure. I'd prefer that it didn't, writing conformant shell scripts is hard enough.
      • kazinator 7y ago
        cut -f is in the standard: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
        • samatman 7y ago
          I'm quite sure we just linked to the same document, were you meaning to address the grandparent?
      • clarry 7y ago
        Before standards happen, creative developers are free to use their imagination and come up with useful features. Then someone makes up a standard, and from thereon progress is halted. The only way you grow new features and functionality is through design-by-committee, if people aren't making extensions that would one day make it to the next revision. I think it is ridiculous. Tools should improve, and standards should eventually catch up & pick up the good parts. People who need to work with legacy systems can just opt not to use those extensions, but one day they too will benefit. Others benefit immediately.
• Scarbutt 7y ago
  And awk doesn't offers cut's column range selection ;)
  • ColinWright 7y ago
    I'm an expert on neither AWK nor cut, but AWK allows you to select a field, or the entire line, and then substrings within those. Select characters 3-6 (inclusive) in the second field: $ echo Testing LengthyString | awk '{print substr($2,3,4)}' > ngth If you want to select columns from the entire line, then: $ echo Testing LengthyString | awk '{print substr($0,3,4)}' > stin Is that what you meant?
    • cauthon 7y ago
      I don't think so. I think they're referring to cut's ability to select an arbitrary range of columns, e.g. `cut -f 2-7` to select the 2nd through 7th columns, while awk requires you to explicitly enumerate all desired columns, i.e. `awk '{print $2, $3, $4, $5, $6, $7}'
      • b215826 7y ago
        > "while awk requires you to explicitly enumerate all desired columns" Or you can use loops, e.g., echo $(seq 100) | awk '{ for (i = 2; i <= 7; i++) { print $i; }; }'
        • hawski 7y ago
          It's more characters than manual way. There should be just a built-in function.
    • deleted 7y ago
      [deleted]
    • Scarbutt 7y ago
      What cauthon said, cut lets you select range of fields with a simple option, awk doesn't, ex(csv line): cut -d, -f10-30 (selects from field 10 to 30) Not saying this can't be written in awk with more code, but we were talking about field selection ergonomics.
• cauthon 7y ago
  > I don't know of any easier equivalent of "awk '{ print $2 }'" for what it does. Does `cut -f2` not work? My complaint with cut is that you can't reorder columns (e.g. `cut -f3,2` ) Awk is really great for general text munging, more than just column extraction, highly recommend picking up some of the basics Edit to agree with the commenters below me: If the file isn't delimited with a single character, then cut alone won't cut it. You need to use awk or preprocess with sed in that case. Sorry, didn't realize that's what the parent comment might be getting at.
  • syncsynchalt 7y ago
    It does not. Compare: $ echo ' 1 2 3' | cut -f2 1 2 3 $ echo ' 1 2 3' | cut -f2 -d' ' $ echo ' 1 2 3' | awk '{print $2}' 2 "-f [...] Output fields are separated by a single occurrence of the field delimiter character."
    • cauthon 7y ago
      oh yes, totally agree. if the data isn't delimited by a single character, then you definitely need awk or sed+cut
    • ratsmack 7y ago
      Also, the field separator (FS) can be a regular expression. FS = "[0-9]"
      • jerf 7y ago
        IIRC, there is an invocation of cut that basically does what I want, but every time I try, I read the manual page for 3 or 4 minutes, craft a dozen non-functional command lines, then type "awk '{ print $6 }'" and move on.
        • masklinn 7y ago
          > IIRC, there is an invocation of cut that basically does what I want I don't think there is, because cut separates fields strictly on one instance of the delimiter. Which sometimes works out, but usually doesn't. Most of the time, you have to process the input through sed or tr in order to make it suitable for cut. The most frustrating and asinine part of cut is its behaviour when it has a single field: it keeps printing the input as-is instead of just going off and selecting nothing, or printing a warning, or anything which would bloody well hint let alone tell you something's wrong. Just try it: `ls -l | cut -f 1` and `ls -l | cut -f 13,25-67` show exactly the same thing, which is `ls -l`. cut is a personal hell of mine, every time I try to use it I waste my time and end up frustrated. And now I'm realising that really cut is the one utility which should get rewritten with a working UI. exa and fd and their friends are cool, but I'd guess none of them has wasted as much time as cut.
• dkarl 7y ago
  I define aliases c1, c2, c3, c4, etc. in my .bashrc as "awk '{print $1}'" etc. But it's nice to have awk for the slightly more complicated cases, up until it's easier to use Python or another language.
  • patrickdavey 7y ago
    I don't suppose your dotfiles are available anywhere. I'm just wondering what other useful things I can steal ;)
    • danwills 7y ago
      I don't have my dotfile here (on my phone) but here's some ideas from things I've aliased that I use a lot: cdd : like cd but can take a file path - : cd - (like 1-level undo for cd) .. : cd .. ... : cd ../.. (and so on up to '.......') nd : like cd but enter the dir too udd : go up (cd ..) and then rmdir xd : search for arg in parent dirs, then go as deep as possible on the other branch (like super-lazy cd, actually calls a python script). ai : edit alias file and then source it Also I set a bindkey (F5 I think) that types out | awk '{print}' followed by the left key twice so that the cursor is in the correct spot to start awk'in ;D # Bind F5 to type out awk boilerplate and position the cursor bindkey -c -s "^[[[E" " | awk '{print }'^[[D^[[D" Edit: better formatting (and at work now so pasted the bindkey)
      • deleted 7y ago
        [deleted]
    • dkarl 7y ago
      Sorry, not much else going on in my dot file except stuff that is peculiar to my current environment.
  • coliveira 7y ago
    awk '{print $1}' can also be written as awk '$0=$1'
• 0xbadcafebee 7y ago
  The Internet Correction Squad would like to remind you that 1) they are different programs that do different things, 2) if they changed over time, they wouldn't be portable, 3) if all you use awk for is '{print $2}', that is perfectly fine. You can submit a new feature request/patch to GNU coreutils' cut, but they'll probably just tell you to use awk. Edit: Nevermind, it's already a rejected feature request: https://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00179.html https://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg... (from https://www.gnu.org/software/coreutils/rejected_requests.html https://www.gnu.org/software/coreutils/rejected_requests.htm...)
  • downerending 7y ago
    One of the bad things about having an ultra-stable core of GNU utils as that they've largely ossified over time. Even truly useful improvements can often no longer get in. It's a sharp and not-entirely-welcome change from the 80s and 90s. Here's another that would be great but will never be added: I want bash's "wait" to take an integer argument, causing it to wait until only that number (at most) of background processes are still running. That would make it almost trivial to write small shell scripts that could easily utilize my available CPU cores.