> People like to pretend that learning shell commands is somehow better because it's more portable,
No, it's better because if you aren't doing exactly the workflow an IDE or GUI tool designer has envisioned, it is almost invariably much easier to do it in shell (and then make it a script and then bind it to a command in your IDE or GUI tool, if they support that) than to beat the non-shell tool into, first, doing what you want, and then making it easily repeatable.
It's also more portable, which, contrary to your description, is very useful for most people, because even if there are some dev-only tasks that “I can only do it in the IDE” is fine for, for many things you may also want to do in a CI pipeline, on a deployment box, or other places where your IDE isn't running. Shell scripts generally work there.
I use IDE mainly for code editing and exploration (e.g. jump from usage to definition), for which I can't see how shell is easier.
Modern IDEs have shell built-in so when I finish coding, I can just open up a terminal inside IDE to run shell scripts. Effectively I'm getting the best of both worlds.
I never knew that I have to follow some sort of rails laid by IDE designers, which I think it's a very common misconception by people who dislike IDEs.
Shells inside IDEs are an idea that goes back to Xerox PARC workstations, the UNIX folks just have an hard time grasping that in spite of urban myths, there aren't other ways to achieve the same.
Even better, because IDE integrated shells are many cases graphical REPLs with additional interaction capabilities and graphical abilities.
As for the travel into memory lane, here out of 1977,
You can have a nice view how it worked, by following the Wikipedia links, or checking the presentation on Mesa/Cedar, which was the evolution of XDE as Mesa evolved into Cedar, and one of the latest version of XDE as well.
"Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0"
The lack of teaching of the computing world outside Bell Labs leads to a UNIX cult, unaware of the progress that was actually already available in the 70 and 80's, but unfortunely failed to pick up due to several reasons, so in the end there is this idolatration of the UNIX shell.
> Modern IDEs have shell built-in so when I finish coding, I can just open up a terminal inside IDE to run shell scripts
Sure. In GP I talk about the value of knowing the shell when you use an IDE, not the value of knowing shell instead of using an IDE. To get “the best of both worlds”, you have to know how to use the shell.
> I never knew that I have to follow some sort of rails laid by IDE designers
You don't, if you know how to use the shell. Whether the shell is integrated or external to the IDE is a side issue.
You missed the point that it’s about user preference. The shell works better for you, that’s great.
My setup is specifically crafted between my text editor (that has a terminal that I use all the time) and a few GUI tools that I’ve got customized and scripted. I like a mix of shell and GUI. That’s my preference.
You’re right that it isn’t as portable as my dot files repo (and I have one of those too), but I do actually have it set so I can quickly restore the whole config on a Mac and restore the text editor portion from Windows, or really any machine with a web browser.
If you are constantly using different machines on the regular, yeah, being good at shell commands makes sense. But it still comes down to personal preference and people who like other methods aren’t inferior.
No, it's better because if you aren't doing exactly the workflow an IDE or GUI tool designer has envisioned, it is almost invariably much easier to do it in shell (and then make it a script and then bind it to a command in your IDE or GUI tool, if they support that) than to beat the non-shell tool into, first, doing what you want, and then making it easily repeatable.
It's also more portable, which, contrary to your description, is very useful for most people, because even if there are some dev-only tasks that “I can only do it in the IDE” is fine for, for many things you may also want to do in a CI pipeline, on a deployment box, or other places where your IDE isn't running. Shell scripts generally work there.