This is true both for working locally and remotely. When connecting remotely, GUIs consume much more bandwidth than terminals, wasting resources. Moreover, latency , i. To quote from this article by Nucleus Research:.
That trend has accelerated, with only 4 percent of projects running on-premise in There are just a few popular shells bash, zsh, fish, ksh, tcsh, cmd, Windows PowerShell, etc. For example, the bash commands that you learn in our command line courses will work on Unix-based machines like Macs and Linux computers. Even if their system doesn't use bash, it'll use something similar enough that you'll be able to figure it out. Research shows that mouse use plateaus rather quickly, while keyboard use, despite its steep learning curve, can be more efficient.
Contrary to our expectations, most experienced users rarely used the efficient keyboard shortcuts, favoring the use of icon toolbars instead. A second study was done to verify that keyboard shortcuts are, indeed, the most efficient method. Six participants performed common commands using menu selection, icon toolbars, and keyboard shortcuts. The keyboard shortcuts were, as expected, the most efficient. Because it is so easy to track all of your activity on the command line, auditing and debugging is much easier.
And, as previously mentioned, many of the bash commands you'll learn work in Windows' native sell options like the command prompt anyway. That means that the command line skills you learn in these courses will be usable on virtually every computer you encounter including your personal machine, no matter what operating system you use.
There is a misconception that using the command line requires you to know several hundred commands. Still not convinced? When I am asked to explain the difference between Windows and Linux, I often use a toy analogy. Windows is like a Game Boy. You go to the store and buy one all shiny new in the box. You take it home, turn it on, and play with it. Pretty graphics, cute sounds.
After a while, though, you get tired of the game that came with it, so you go back to the store and buy another one. This cycle repeats over and over. The games are all sealed up in their cartridges. You discover that your toy is limited to the games others have decided that you need. So, you start to play with it.
However, is it worth it in the long run? One of my other profs mentioned that he's not sure why they are teaching bash scripting in this class and that "python will replace bash scripts". I'm not concerned whether if someone thinks python is better. That sounds subjective. So the question is - Is it worth the time and effort to learn bash scripts? Are these popular in the enterprise environment such as say on a job? Or am I just investing time into something obsolete that will become obsolete in the not too distant future?
Sorry if this is a report. I used the search but could not come up with any decent conclusion. Join Date: Jun It depends on where you are going to work and on which domain. If you have any idea on that probably we can suggest. Well I'm thinking most likely in a corporate environment. I do realize many corporations will use technologies that are obsolete i.
Join Date: Aug This question is almost too good: "Hm I could go to unix. Eh, a bit too obvious. I know -- ask that about an unusual shell, one that divides the community, in a manner that suggests I believe it's all shell scripting!
The nerd rage will be hysterical! Is BASH obsolete? Is it for the things you use C or Python for? Also no. Scripting is somewhere between difficult and useless on a Windows machine because there are so many unscriptables awkward, undocumented, or impossible. Ever had to type in the same thing, or closely related things, 37 seperate times? Ever had to sit and wait for the computer to finish just so you can tell it to do something you wanted it to do all along?
That's the kind of automatic tasks shell scripting and pipes are for. They join entire programs together at a very high level, if they're equipped to communicate that way; most UNIX programs are, most Windows ones aren't.
You should learn shell scripting, not just "bash scripting". BASH is just one shell. Last edited by Corona; at PM.. Find all posts by Corona There seems to be a scale ranging from bare metal to functional programming. It would be an interesting exercise to see which concepts make code more expressive for you, and which for me, and if there are certain 'clusters' of developers that benefit from the same kind of style.
Probably there are some studies about it already - I'll have to look around. I use bash day in and day out. It's my favorite shell. I've been using it for a long time. I use git for source control. I have my code peer reviewed. I've converted some other peoples bash scripts into Python.
I've converted some other peoples Perl scripts into Python. I've converted some other peoples JavaScript on Node. Because I love Python? Well, I am fond of it, true. No, because the other code was hard to understand and hard to maintain and hadn't been code reviewed and wasn't abiding by the approved scripting engines.
The "hard" part isn't a shortcoming of the language after all, these aren't PHP , it's a shortcoming of the programmer making a tasty pot of spaghetti code -- and spaghetti code can be written in any language. Examples are everywhere. Shell and to a lesser extent Perl is plentiful in the wild - and it is mostly the awful stuff that is most readily available. If you did the conversions in a company, and everyone else can write clean Python then great : Although perhaps getting people to write clean lang-x in the first place would have been just as productive.
I speak from experience when I say trying to make people learn and write clean shell is a pain. That is a valid counterpoint, and I concur. Good code can be written in any language, except PHP of course. The process made me think about this special language's place in the world. I came to the following conclusion:. Shell is a real language.
It's focused in specific areas of software development. If you try to venture out of those areas, you'll hit a wall. If you know you'll never venture out, then it's totally fine to use it. Shell lacks data structures, proper maths and string operations are awkward at best, so it's not a good language to work on data. It's perfectly suited for DevOps, gluing different programs together and day-to-day development low-level tasks. As these are all important areas of software development, shell code should be treated as importantly as the code you write that works with data or business rules; it's also part of the system you're building!
It is a language with a specific use case in mind, that of chaining tools. The mistake often made is trying to, as you say, venture into incompatible areas, where problems quickly pile up. POSIX compatibility is a bit of a gripe of mine - it's there to ensure cross-compatibility, so that's definitely a bonus, but those specifications are so restrictive that they cripple a number of capabilities various shells have come up with to "resolve" the issues of POSIX.
One of them is array iteration - decently well fixed in bash, and probably workable in most other shells, but quite horrific to handle in POSIX sh.
With properly setup server management practices, it should be possible to mandate any software required, so bash would be my choice to mandate, but other teams prefer other shells, and that's fine too.
Mind that I'm not saying that bash and shell scripting is bad - on the contrary I love it. I'm mostly saying that people generally don't bother to learn to use it well and for its use-case, and so we end up with a default quality of scripting across the board that is horrific - and that level of quality is passed on because that's what expected. And so my message became a distorted one: "for pity's sake..
If it's a clearly OS- or file-system-centric or especially stream-oriented task, same. If it seems like it's going to be complex with optional arguments or different types of runs, straight to Python. As soon as what was a straight-forward Bash script starts getting requests to do more stuff, rewrite it in Python. It was solid, effective, fast, and even configurable with the ability to add new checks using regular expressions.
But that was the point at which I said "never again" for something like that. The last I heard, it's still in use a decade later and has hardly been touched except for a little tweak here or there due to some network changes. They actually use it to vet any new tool they bring in. So I'm pretty proud of that, even if I'd never write such a monstrosity now.
There's some extra management in there to prevent double-including files two dependencies with a shared third dependency etc. Bash can definitely give you a bit of a Frankenstein complex, simultaneously proud and horrified at what you've created. Bash and sh relatives is probably the most valuable and yet poorly understood scripting language in existence.
This owes largely to confusion about the nature of subshells and ignorance of the 'source' command, as well as ignorance of the builtin regular expression parsing facility and associative arrays. Shell languages are great when used as "glue" logic, it becomes iffy when you start trying to do "business" read: "non-glue" logic in them Function re-usability is important for good practice and reducing repetition etc, but if two re-used files re-source a same file, things can get messy This problem was actually my primary motivation for creating bash-builder: a set of re-usable "libraries" that could be re-used in building other scripts Use it lots.
There are ways around it install , but sometimes it's not always possible I did once write a web server in bash If that script grows arms and legs, you'll have wanted it to be just the glue that calls the more complex parts in other-lang. I just wrote them cleanly, namespaced the heck out of the functions, and re-used code as much as possible the reason behind my bash-builder project.
I mean yes, I do agree with your points, but life has surprises, of which Inexperienced Colleagues is but one of many! Like I said, I've seen utter trash written by otherwise competent coders. I don't know why the discipline goes out the window as soon as they face bash. Probably if I threw Haskell at them they'd try to learn it properly. But shell? It's similar enough to C and JavaScript that they can write stuff, but sufficiently idiosyncratic that they just want to be over with it already.
However, shell is FULL of moving dependencies. Each of these can have in varying forms different implementations of mail , grep , rsync , sed. There have been so many times I've started writing a shell script, midway thought that the task would he so much better solved in python, but continued writing shell anyway. I do agree, for most people Python with a shell script calling the python function is going to be a better solution. This is where PowerShell shines. Cross platform, shell capable, rich objects and ecosystem.
Pester test framework supports tested robust modules. If dotnet is in your environment it works great and the pipeline is powerful. I was surprised at how much of a transition I had leaving windows behind and moving to macOS and docker based workspaces. Most of my stuff runs smoothly on all 3 systems.
I never gave PowerShell a go on anything other than Windows I found it there to be excessively verbose for a command language, but I can see where that might in fact improve its use as a scripting language.
The availability of object output from tools is certainly a step up from parsing text streams especially those that are designed for on-screen display, instead of automations , but then that puts the onus on the tool writer to write for that compatibility. I'd more readily have a JSON parser in lang-x and use it to extract from the outputs from other tools, and standardise other tools around JSON seems to be the most common thing to handle these days.
This could even unify web-API-based programming and shell programming nicely Question remains though - is most of its functionality derived from built-in functions, or calls to commands actual executables in the local system? Not sure, but as I understand you, you are running the same PS in Windows and non-Windows environments? Also what's the average quality of examples out in the wild to learn from?
Comment, separate variables from content, and separate concerns into separate functions or files in the case of bash. If someone comes to you and asks you what the code you wrote a year ago is doing, 1 you already messed up, and 2 if you can't figure it out in a matter of moments, then you messed up.
Most of us have been in this situation, so we can only strive to do better. For me, the last thing I want to do is debug a very large bash script, so I go for another language Python, C, etc. That said, I've been reviewing code recently for various CI developers. If I show them how their Python is not clean and there is a better way they're "huh yeah I get it, I'll try to remember that for next tiem".
I do the same thing with their shell and they're "yeah, my shell skills are bad haha, anyway, moving on. Yeah, I learned shell scripting, but not all the good encapsulation techniques. Powershell has much in the way of being a better language than bash.
However I concluded much different from you. I decided shell scripting wasn't worth the additional learning and maintaining. However I can get our IT to make a decent text editor available on every server build, everyone uses notepad so Bash script, it's a glorified toy language
0コメント