31–40 of 138 posts
And not even one mention of man pages... That is was my main resource for learning new (remembering old) commands. Maybe it's out of date now due to google, but if you're already in the terminal man is the way to go. Also, I feel like cat and less should have separate explanations as they have diverging utilities.
"The only way to learn what these mean is to look them up through Google or by typing 'man grep'. "
Earlier quoted context omitted.
Because people assume they should RTM and if memory serves me right it is a whole lot more confusing than your post :-)
Doesn't look any more complex than most man pages: https://linux.die.net/man/1/tar
Great list for starters. But getting real work done requires much more. Having just walked through some basic steps with a novice, I can concur, modern linux is impossible without "recipes". Just setting up a hello world web app can involve: ssh login to running instance, using curl to download the gcloud sdk, tar to unpack, sudo to install, systemctl to start local processes, useradd dedicated www, chmod and chroot…
ssh login to running instance
using curl to download the gcloud sdk
tar to unpack
sudo to install
systemctl to start local processes
useradd dedicated www
chmod and chroot to allow access
rsync to tranfer files
People who cannot even handle those tasks should not use a root server for their project. There are alternatives to a full system, if running a single app with a database is your use case. Be it Heroku or Lambda, there are solutions that do not need administrator knowledge to run an application.
To add to this, servers that are lousily configured because some developer did not know what platform to use damages the infrastructure as a whole. They are broken in, used for spam or data theft if the application has some user base. If you know someone who does not know how to handle a system, please advice them to either coop with an admin or to not use a full system for their project.
One example of this is the popular version control system (VCS) called git. Developers could have written this software to work on Windows, but they didn't. They wrote it to work on the command line for Linux because it was the ecosystem which already had all the tools they needed. I think the real (and even stronger) reason is that Linus Torvalds specifically built Git to serve as the VCS for the Linux codebase.
Learning to do a thing and learning to do a thing well enough to create a production quality result that isn't a liability to the company are very different. That said, improving Linux knowledge among those who had little/none before is a net win in the long term IMO.
Earlier quoted context omitted.
Because people assume they should RTM and if memory serves me right it is a whole lot more confusing than your post :-)
Doesn't look any more complex than most man pages: https://linux.die.net/man/1/tar
This is not a surprise - the Windows ecosystem simply wasn't designed with software development in mind.
This article is so bad, I'm really getting mad over here. Stop publishing such crap, you feed a lot of people's resentment against all those hipster developers who don't want to learn by RTFM, but want to have handled everything.
Articles like this are a real hurdle on the way towards making Linux and programming in general more approachable to non-techies. Just stop, please.
Earlier quoted context omitted.
Over years I've heard a lot of complains on tar being hard to use, but in real-life I really ever had to use only these two commands: tar zcvf and tar zxvf. It's actually quite easy to remember: tar Zip Compress Verbose File, and tar Zip eXtract Verbose File.
It's even easier than that! Less memorization, more understanding. You can think of Tar arguments as either subcommands or options . The dashes are optional The "subcommands" are x (extract), c (create), t (list), among others. The "options" are f (read from named file rather than stdin), v (verbose mode), and z (run gzip on the archive before processing). The fact that these options can be written without leading da…
Earlier quoted context omitted.
Doesn't look any more complex than most man pages: https://linux.die.net/man/1/tar
Part of my point: most of them are complex and to a big degree unnecessarily complex.
tar cvf somedir filename.tar create an archive from somedir and store it in filename.tar
tar xvpf filename.tar extract the contents of filename.tar and scatter them around your home directory
Instead of getting examples that I might use, when I visit a man page, I get a wall of text 926 lines long, describing every possible option, including GNU option styles, or some truncated mess telling me to read the info pages.
Of course, it's appropriate that all this information is included somewhere in the manual. I just think the common use cases should be first. Does anyone need a man page for 'ls' that starts off describing how to list inode numbers and SELinux labels?
One example of this is the popular version control system (VCS) called git. Developers could have written this software to work on Windows, but they didn't. They wrote it to work on the command line for Linux because it was the ecosystem which already had all the tools they needed. I think the real (and even stronger) reason is that Linus Torvalds specifically built Git to serve as the VCS for the Linux codebase.