3 ms·

Hear hear! I've had a sed book on my shelf for years and I've used it more than once, but 99% of the time I end up giving up on sed and using a GUI-based tool

Hear hear! I've had a sed book on my shelf for years and I've used it more than once, but 99% of the time I end up giving up on sed and using a GUI-based tool instead of trying to concoct the cryptic lines given above as examples. I absolutely would rather use the clean interface of replace, written in JavaScript or anything else, than to memorize that steaming pile of cruft.

Domenic_S 14y ago
Two reasons why it's better to memorize the cruft: 1. You can pipe find/sed/grep/cut/awk/whatever to other utils. Today you might be replacing, tomorrow you might be analyzing text logs, and the more core utils you learn the more things you can do with them. 2. When you're ssh'd into another box that doesn't have that spiffy replace utility, now you don't know how to do an inline replace.
- cjg 14y ago
  Your argument that it wouldn't be available on other boxes can be applied against any new command, no matter how fantastic, so it doesn't seem very constructive to me.
  - webreac 14y ago
    I think it is a good argument to learn basis before reinventing the wheel. When using unix, there are already far too many commands to learn. Not having to learn useless commands is a bonus.
    - chris_wot 14y ago
      And yet, it's not useless to so many.
  - yb66 14y ago
    I agree wholeheartedly. As an example, many languages are Turing complete and yet we still keep creating new languages when just one (theoretically) would do. It's because syntax is separate from meaning, syntax matters (compare addition in Roman numerals to our current number system, same meaning, improved syntax). Also, problem domains differ, but here it's a problem of syntax, and the argument against "reinventing the wheel" is moot if you're moving from a wooden wheel to one with spokes and a tyre.
- chris_wot 14y ago
  1. Perhaps learn that when you actually need to analyze text logs? 2. Perhaps you don't need to do this. Or perhaps you'll work it out when you ssh into another box.
- doktrin 14y ago
  > 1. You can pipe find/sed/grep/cut/awk/whatever to other utils. Today you might be replacing, tomorrow you might be analyzing text logs, and the more core utils you learn the more things you can do with them. Fair. This boils down to an individual's needs. I think most people in a position to be making this choice are fairly well aware of what's possible with standard nix CLI tools, and can decide whether or not to invest the time to learn them. In my experience the ROI for nix wizardry is fairly high at first, but begins tapering off. There are a half dozen or so command chains I use daily without which I could hardly see myself working, and the rest I may not touch for weeks or months on end. YMMV. > 2. When you're ssh'd into another box that doesn't have that spiffy replace utility, now you don't know how to do an inline replace. It doesn't make sense to optimize a workflow around an edge case. You don't often hear this brought up as an argument against dotfiles, key bindings, vim plugins or what have you.
  - pekk 14y ago
    You actually do hear this brought up as a case against dotfiles and vim plugins, even the use of vim as opposed to vi. There is just this school of thought which says you should never use anything which isn't in a default CentOS install.
    - caw 14y ago
      As a sysadmin, I can totally relate to those thoughts. If you run nonstandard, you basically have to learn vim/vi as a default install for an OS and another with all your add-ins and customization. Sure the key bindings are similar, but I don't have my macros and why is my tabbing funny, there's no line numbers, and damn it, the backspace key doesn't work. I forgot I set that in my .vimrc. Sure, I can remember most of the latter with set tab and set no, but when you're popping around systems, switching to root (with it's on .vimrc), keeping applications as stock as possible is very helpful. I personally have a slightly custom .vimrc for my local use, but I don't rsync my dotfiles across the globe for my other home directories. I basically try to keep it as code development (with .vimrc) and sysadmin (may not have niceties, but I'm not editing code).
- SomeCallMeTim 14y ago
  I know the core basics of find/sed/grep and I've even used awk on occasion (though I typically have to Google for that one), and occasionally I use them when I'm ssh'ed into a box. But as soon as I want to do something more sophisticated, I again reach for the tools I know better. No I can't use my GUI tool on a box I'm ssh'ed into, but I can push my changes to a git repository and pull them to be local, where I can do complex things really quickly and without having to memorize tons of obscure options and corner cases. In a case where that's not as feasible (hundreds of megabytes of log files, say), and what I need is beyond my find/sed/grep skills, I usually drop into my language-of-choice and produce a tool that is much easier to use for my purposes. Honestly I haven't touched awk in a long time because the pain is so much greater in awk to accomplish what I can in my own more familiar toolset. I get that those tools work fine for any old-school Unix hacker, and the combination is quite powerful in its own right. I don't have the desire to BE an old-school Unix hacker, though, and my tool-set is quite powerful enough to accomplish what I need without going through that particular hazing ritual, thank you. My need for tools like this happens rarely enough that even if it would be faster once I'd learned the tools to type out the appropriate command line, the amortized time to GET to that skill level in those tools would be far more than the time it takes me to just use my "less optimal" tools.

Domenic_S 14y ago

Two reasons why it's better to memorize the cruft: 1. You can pipe find/sed/grep/cut/awk/whatever to other utils. Today you might be replacing, tomorrow you might be analyzing text logs, and the more core utils you learn the more things you can do with them. 2. When you're ssh'd into another box that doesn't have that spiffy replace utility, now you don't know how to do an inline replace.

cjg 14y ago
Your argument that it wouldn't be available on other boxes can be applied against any new command, no matter how fantastic, so it doesn't seem very constructive to me.
- webreac 14y ago
  I think it is a good argument to learn basis before reinventing the wheel. When using unix, there are already far too many commands to learn. Not having to learn useless commands is a bonus.
  - chris_wot 14y ago
    And yet, it's not useless to so many.
- yb66 14y ago
  I agree wholeheartedly. As an example, many languages are Turing complete and yet we still keep creating new languages when just one (theoretically) would do. It's because syntax is separate from meaning, syntax matters (compare addition in Roman numerals to our current number system, same meaning, improved syntax). Also, problem domains differ, but here it's a problem of syntax, and the argument against "reinventing the wheel" is moot if you're moving from a wooden wheel to one with spokes and a tyre.
chris_wot 14y ago
1. Perhaps learn that when you actually need to analyze text logs? 2. Perhaps you don't need to do this. Or perhaps you'll work it out when you ssh into another box.
doktrin 14y ago
> 1. You can pipe find/sed/grep/cut/awk/whatever to other utils. Today you might be replacing, tomorrow you might be analyzing text logs, and the more core utils you learn the more things you can do with them. Fair. This boils down to an individual's needs. I think most people in a position to be making this choice are fairly well aware of what's possible with standard nix CLI tools, and can decide whether or not to invest the time to learn them. In my experience the ROI for nix wizardry is fairly high at first, but begins tapering off. There are a half dozen or so command chains I use daily without which I could hardly see myself working, and the rest I may not touch for weeks or months on end. YMMV. > 2. When you're ssh'd into another box that doesn't have that spiffy replace utility, now you don't know how to do an inline replace. It doesn't make sense to optimize a workflow around an edge case. You don't often hear this brought up as an argument against dotfiles, key bindings, vim plugins or what have you.
- pekk 14y ago
  You actually do hear this brought up as a case against dotfiles and vim plugins, even the use of vim as opposed to vi. There is just this school of thought which says you should never use anything which isn't in a default CentOS install.
  - caw 14y ago
    As a sysadmin, I can totally relate to those thoughts. If you run nonstandard, you basically have to learn vim/vi as a default install for an OS and another with all your add-ins and customization. Sure the key bindings are similar, but I don't have my macros and why is my tabbing funny, there's no line numbers, and damn it, the backspace key doesn't work. I forgot I set that in my .vimrc. Sure, I can remember most of the latter with set tab and set no, but when you're popping around systems, switching to root (with it's on .vimrc), keeping applications as stock as possible is very helpful. I personally have a slightly custom .vimrc for my local use, but I don't rsync my dotfiles across the globe for my other home directories. I basically try to keep it as code development (with .vimrc) and sysadmin (may not have niceties, but I'm not editing code).
SomeCallMeTim 14y ago
I know the core basics of find/sed/grep and I've even used awk on occasion (though I typically have to Google for that one), and occasionally I use them when I'm ssh'ed into a box. But as soon as I want to do something more sophisticated, I again reach for the tools I know better. No I can't use my GUI tool on a box I'm ssh'ed into, but I can push my changes to a git repository and pull them to be local, where I can do complex things really quickly and without having to memorize tons of obscure options and corner cases. In a case where that's not as feasible (hundreds of megabytes of log files, say), and what I need is beyond my find/sed/grep skills, I usually drop into my language-of-choice and produce a tool that is much easier to use for my purposes. Honestly I haven't touched awk in a long time because the pain is so much greater in awk to accomplish what I can in my own more familiar toolset. I get that those tools work fine for any old-school Unix hacker, and the combination is quite powerful in its own right. I don't have the desire to BE an old-school Unix hacker, though, and my tool-set is quite powerful enough to accomplish what I need without going through that particular hazing ritual, thank you. My need for tools like this happens rarely enough that even if it would be faster once I'd learned the tools to type out the appropriate command line, the amortized time to GET to that skill level in those tools would be far more than the time it takes me to just use my "less optimal" tools.