5 ms·

I like the "everything is text" mentality, but really, the "hard part" of the GNU/Linux CLI is getting things done when you don't already know how. If you've m

by l_t 8y ago

I like the "everything is text" mentality, but really, the "hard part" of the GNU/Linux CLI is getting things done when you don't already know how. If you've memorized the hundreds of different invocation arguments for find, sed, grep, tr, sort, uniq, cat, xargs, etc. -- then yes, you can be very fast. If not -- be prepared to RTFM for about 4 different programs to get your job done. That's an incredible hurdle and it really only makes sense if you are using these tools daily/weekly. I'm still not completely convinced that its "worth it" to master these tools, when general-purpose scripting languages are almost as succinct and obviously way more powerful. That's speaking as someone who's written a fair amount of Bash. In contrast, I think tools with higher discoverability and self-documenting nature (arguably, Excel) usually offer a more user-friendly way of doing the same thing, unless you are doing it a lot.

pm215 8y ago
Yes, most of us would probably have to check the manpage for three or four of these utility programs to put together something like Rob McIlroy's one-liner from the article. I think this is clearly still more efficient than writing 17 pages worth of code in a general purpose language, which is what it's being pitted against. I also don't think it's really a very high hurdle -- if I were writing the same thing in a Python or Perl script I bet I would end up also consulting the documentation to check exactly how to do things or what some detail of syntax is. If you happen to write Python all day every day then sure, you'll find it much faster to just write a quick Python script for this sort of thing. If your day job is C or Java or some other non-scripting language and this is a once-a-month-or-so task then I think the time required to do this sort of small utility task in shell-and-utility-tools is not really any different to remembering how to write Perl scripts.
- pfranz 8y ago
  I do see what they're saying though. I've used Linux for the most part of 20 years. My primary job has hopped between Perl, Python, and a bunch of other languages, but bash/csh has been fairly consistent. I took a job using Windows for a year or two and tried really hard to get familiar and proficient in PowerShell. Since my job was primarily in Python, learning PowerShell had a steep learning curve with a lot of time between uses. I clung to Python. I jumped to WSL/Ubuntu (and honestly sshed into Linux vms before that) because I was so familiar with it. If I stayed at that job (or another Windows job) I probably would have eventually picked up PowerShell, but that would probably have taken 5 years.
- jamesgeck0 8y ago
  The 17 pages comment gets me. Literate programming is verbose by design. I'd be surprised if the Ruby version of that script was much longer than the command line version.
- Wowfunhappy 8y ago
  And, it's also faster/easier to copy and paste a command from the internet than to download, install, and run a standard program. Probably not the most security-conscious thing, but it gets the job done. Furthermore, it's often quite easy to slightly tweak a command I found online, even if I don't understand much of it.
pfranz 8y ago
I agree. I think a REPL (which I consider the command line to be one of) and something like Excel to be immensely useful no matter what the language or proficiency. I think code is much sturdier and I'm more likely to experiment if I can iterate over code after typing every few words instead of (even in a language I'm proficient at) writing a whole page of code, then running it to correct my typos and errors. I work in visual effects. Most of our software has a build-in Python interpreter. I was talking to a tech savvy junior who was interested in becoming a full time modeler/artist. He was asking if he should learn programming/Python and I advised against it (unless it scratched his particular itch). I felt his efforts were best put towards getting better at modeling. Most large places I've worked at the artist can get by with a sticky note of common commands. There's usually someone they can ask for advice or small scripts when things get hairy. Smaller places you're more on your own. But it is surprising when you have 100+ items, you need to be sure they all have 2 sets of UVs. The manual way is to click on each one and pull a drop-down menu or with Python you can write a one-line foreach to test and print. It's all about knowing which screw to turn[1] I often challenge myself in doing something in a single line just to scratch my own itch. Often when tackling daunting tasks (do this thing 20-50x) I weigh the benefit of doing it manually, but bias a tad toward automating even if I'm throwing the code away. But I don't think it's worth most people's time. The biggest benefit of working the same place a long time is knowing who to ask about things. Second is knowing the history of things. Third is having a junk drawer of scripts that don't quite work out of the box, but they have idioms I can grab when I need to hammer something out. [1] https://calvincorreli.com/blog/1397-knowing-which-screw-to-turn https://calvincorreli.com/blog/1397-knowing-which-screw-to-t...
- pasabagi 8y ago
  I do a lot of 3d stuff (not a pro) and I've found a passing knowledge of programming is quite useful when you're doing something a little bit more unusual or complex. I did some pretty big cityscapes made out of modular components, and it was nice to have python for stuff like twisting 300 TV aerials so they're all a little bit differently wonky, or making lines of washing. I'm also a big believer in mastering your tools. An artist is limited by their imagination - and imagination is largely structured by your knowledge of materials and the capabilities of tools. If you're working with 3d models, and you plan on mastering it, having an idea of what you can do with An artist is limited by their imagination - and imagination is largely structured by your knowledge of materials and the capabilities of tools. It spurs you on to try new and ambitious stuff, new styles, new forms.
falcrist 8y ago
As a Windows user (embedded programming and gaming keeps me stuck to Windows) who has dabbled a bit in Linux over the last 10 years, the fact that GNU/Linux "assumes you know what you're doing" is constantly frustrating. I've overcome this somewhat by stopping my current linux install from automatically starting the xwindow system. That way I have to use the terminal for some things. This has worked somewhat, but seems only to highlight how terrible interface is for those of us who aren't wizards. I like to phrase it as "Linux assumes you know what you're doing. Windows assumes you don't know what you're doing. Mac assumes you don't want to know what you're doing." Working in an interface that doesn't hold your hand can be liberating when you understand how that system works, but there must be a way we can step back. Maybe it would be worth adding something similar to the drop-down auto-completion boxes I see in so many modern IDEs. That way instead of reading the man page of every single command and program, I can (for example) get a list of possible arguments, and each of those arguments provides a summary of its function when highlighted. This could all be done in text, so that it would be available outside of the window system. Maybe it has already been done. Obviously such a system would be laborious to implement and obnoxious to seasoned bash users (though it should be easy to disable), but it would be extremely handy to those who (like me) only occasionally use Linux. In any case, something should be done that makes the system a little more welcoming to casual users.
- koffiezet 8y ago
  Both Windows and OSX are "GUI first" OS's, and Linux simply is not. The majority of the Linux systems out-there is headless - and it shows. I drop down to a terminal immediately on any Linux system for everything - GUI or not. On both Windows and OSX, I will most likely do things "the GUI" way first, especially file management with the finder or explorer - although on both these platforms, there are very viable or even excellent CLI environments. But I get what you're saying - even when looking at the PowerShell design, script documentation is a first class citizen there. As a scripting language I'm pretty impressed with it, but as a shell I find it an annoying place to be in. OSX on the other hand simply has a unix shell, with a respectable amount of CLI tools available to interact with the desktop. Sadly, Apple scripting has been a bit neglected in the last few releases and is not really supported anymore by all applications. disclaimer: I do not like Linux on desktop. My daily driver is a MBP with OSX, and I used to work on Windows (but still have a gaming box), and all my linux boxes are servers.

by l_t 8y ago

pm215 8y ago

Yes, most of us would probably have to check the manpage for three or four of these utility programs to put together something like Rob McIlroy's one-liner from the article. I think this is clearly still more efficient than writing 17 pages worth of code in a general purpose language, which is what it's being pitted against. I also don't think it's really a very high hurdle -- if I were writing the same thing in a Python or Perl script I bet I would end up also consulting the documentation to check exactly how to do things or what some detail of syntax is. If you happen to write Python all day every day then sure, you'll find it much faster to just write a quick Python script for this sort of thing. If your day job is C or Java or some other non-scripting language and this is a once-a-month-or-so task then I think the time required to do this sort of small utility task in shell-and-utility-tools is not really any different to remembering how to write Perl scripts.

pfranz 8y ago
I do see what they're saying though. I've used Linux for the most part of 20 years. My primary job has hopped between Perl, Python, and a bunch of other languages, but bash/csh has been fairly consistent. I took a job using Windows for a year or two and tried really hard to get familiar and proficient in PowerShell. Since my job was primarily in Python, learning PowerShell had a steep learning curve with a lot of time between uses. I clung to Python. I jumped to WSL/Ubuntu (and honestly sshed into Linux vms before that) because I was so familiar with it. If I stayed at that job (or another Windows job) I probably would have eventually picked up PowerShell, but that would probably have taken 5 years.
jamesgeck0 8y ago
The 17 pages comment gets me. Literate programming is verbose by design. I'd be surprised if the Ruby version of that script was much longer than the command line version.
Wowfunhappy 8y ago
And, it's also faster/easier to copy and paste a command from the internet than to download, install, and run a standard program. Probably not the most security-conscious thing, but it gets the job done. Furthermore, it's often quite easy to slightly tweak a command I found online, even if I don't understand much of it.

pfranz 8y ago

I agree. I think a REPL (which I consider the command line to be one of) and something like Excel to be immensely useful no matter what the language or proficiency. I think code is much sturdier and I'm more likely to experiment if I can iterate over code after typing every few words instead of (even in a language I'm proficient at) writing a whole page of code, then running it to correct my typos and errors. I work in visual effects. Most of our software has a build-in Python interpreter. I was talking to a tech savvy junior who was interested in becoming a full time modeler/artist. He was asking if he should learn programming/Python and I advised against it (unless it scratched his particular itch). I felt his efforts were best put towards getting better at modeling. Most large places I've worked at the artist can get by with a sticky note of common commands. There's usually someone they can ask for advice or small scripts when things get hairy. Smaller places you're more on your own. But it is surprising when you have 100+ items, you need to be sure they all have 2 sets of UVs. The manual way is to click on each one and pull a drop-down menu or with Python you can write a one-line foreach to test and print. It's all about knowing which screw to turn[1] I often challenge myself in doing something in a single line just to scratch my own itch. Often when tackling daunting tasks (do this thing 20-50x) I weigh the benefit of doing it manually, but bias a tad toward automating even if I'm throwing the code away. But I don't think it's worth most people's time. The biggest benefit of working the same place a long time is knowing who to ask about things. Second is knowing the history of things. Third is having a junk drawer of scripts that don't quite work out of the box, but they have idioms I can grab when I need to hammer something out. [1] https://calvincorreli.com/blog/1397-knowing-which-screw-to-turn https://calvincorreli.com/blog/1397-knowing-which-screw-to-t...

pasabagi 8y ago
I do a lot of 3d stuff (not a pro) and I've found a passing knowledge of programming is quite useful when you're doing something a little bit more unusual or complex. I did some pretty big cityscapes made out of modular components, and it was nice to have python for stuff like twisting 300 TV aerials so they're all a little bit differently wonky, or making lines of washing. I'm also a big believer in mastering your tools. An artist is limited by their imagination - and imagination is largely structured by your knowledge of materials and the capabilities of tools. If you're working with 3d models, and you plan on mastering it, having an idea of what you can do with An artist is limited by their imagination - and imagination is largely structured by your knowledge of materials and the capabilities of tools. It spurs you on to try new and ambitious stuff, new styles, new forms.

falcrist 8y ago

As a Windows user (embedded programming and gaming keeps me stuck to Windows) who has dabbled a bit in Linux over the last 10 years, the fact that GNU/Linux "assumes you know what you're doing" is constantly frustrating. I've overcome this somewhat by stopping my current linux install from automatically starting the xwindow system. That way I have to use the terminal for some things. This has worked somewhat, but seems only to highlight how terrible interface is for those of us who aren't wizards. I like to phrase it as "Linux assumes you know what you're doing. Windows assumes you don't know what you're doing. Mac assumes you don't want to know what you're doing." Working in an interface that doesn't hold your hand can be liberating when you understand how that system works, but there must be a way we can step back. Maybe it would be worth adding something similar to the drop-down auto-completion boxes I see in so many modern IDEs. That way instead of reading the man page of every single command and program, I can (for example) get a list of possible arguments, and each of those arguments provides a summary of its function when highlighted. This could all be done in text, so that it would be available outside of the window system. Maybe it has already been done. Obviously such a system would be laborious to implement and obnoxious to seasoned bash users (though it should be easy to disable), but it would be extremely handy to those who (like me) only occasionally use Linux. In any case, something should be done that makes the system a little more welcoming to casual users.

koffiezet 8y ago
Both Windows and OSX are "GUI first" OS's, and Linux simply is not. The majority of the Linux systems out-there is headless - and it shows. I drop down to a terminal immediately on any Linux system for everything - GUI or not. On both Windows and OSX, I will most likely do things "the GUI" way first, especially file management with the finder or explorer - although on both these platforms, there are very viable or even excellent CLI environments. But I get what you're saying - even when looking at the PowerShell design, script documentation is a first class citizen there. As a scripting language I'm pretty impressed with it, but as a shell I find it an annoying place to be in. OSX on the other hand simply has a unix shell, with a respectable amount of CLI tools available to interact with the desktop. Sadly, Apple scripting has been a bit neglected in the last few releases and is not really supported anymore by all applications. disclaimer: I do not like Linux on desktop. My daily driver is a MBP with OSX, and I used to work on Windows (but still have a gaming box), and all my linux boxes are servers.