Go prior to modules worked really well this way and I believe Ubuntu was using it like this, but the Go authors came out against using it as a scripting language like this.
Go prior to modules worked really well this way and I believe Ubuntu was using it like this, but the Go authors came out against using it as a scripting language like this.
Maybe this will make it seem like a more viable approach.
[1]: https://learn.microsoft.com/en-us/powershell/module/powershe...
Theres a fair argument that complex scripts require a complex scripting language, but you have to have a good reason to pick powershell.
Typically, on non-windows, there is not one.
Its the same “tier” as bash; the thing you use because its there and then reach past for hard things. The same reason as bash.
Theres no realistic situation I would (and Ive written a lot of powershell) go, “gee, this bash script/makefile is too big and complex, lets rewrite it in powershell!”
I think PowerShell was totally right to call this out and do it better, even though I don't particularly love the try-catch style of exception handling. False is not an error condition, exceptions are typed, exceptions have messages, etc.
The problem with PowerShell coming from bash etc. is that the authors took one look at Unix shells and ran away screaming. So features that were in the Bourne shell since the late 1970s are missing and the syntax is drastically different for anything non-trivial. Other problems like treating everything as UTF-16 and otherwise mishandling non-PowerShell commands have gotten better though.
Dotnet is a pig with its dependencies by comparison.
If you are a dotnet dev shop, it is quite likely that dotnet is also a tool that is already there the places you need automation.
Plus, its also the tool that is already there in your team’s skillset.
Pros:
Syntax + access to familiar shell commands
Cons:
Bash scripts are not easy to maintain.
Argument about bash being always there breaks down quickly. Even if you limit yourself to bash+awk+grep, they dont work consistently across different bash flavors or across platforms (mac/win/linuz).
My approach now is to have my programs, in the language most convenient to me, compiled to a bunch of archs and have that run across systems. One time pain, reduces over time.
IMO this is why Perl was invented and you should just use Perl. Bash isn't portable and isn't very safe either. If you're only going to use a couple of commands, there's really no reason to use bash. The usecase, in my head, for bash is using a variety of unix utils. But then those utils aren't portable. Perl is really great here because it's available on pretty much every computer on Earth and is consistent.
A lot of people focus on Perl's bad reputation as one of the first web languages instead of its actual purpose, a better sh/awk/sed. If you're writing shell scripts Perl's a godsend for anything complex.
This can be managed but you have to manage it.
(A fanatical commitment to backwards compatibility can make this a lot easier, but it doesn't seem to me that dotnet has that.)
Bash has a huge number of footguns, and a rather unusual syntax. It's not a language where you can safely let a junior developer tweak something in a script and expect it to go well. Using a linter like ShellCheck is essentially a hard requirement.
If you're working in a team where 99.9% of the code you're maintaining is C#, having a handful of load-bearing Bash scripts lying around is probably a Really Bad Idea. Just convert it to C# as well and save everyone a lot of trouble.
I'd say as someone who started with shell/bash in ~ 2000 to cater Linux systems, it's quote usual syntax and I believe that's true for many sysadmins.
No way I'd like to deal with opaque .Net or even Go stuff - incapable of doing "bash -x script.sh" while debugging production systems at 3AM. And non production as well - just loosing my time (and team time) on unusual syntax, getting familiar with nuget and ensuring internet access for that repos and pinging ITSec guys to open access to that repos.
> let a junior developer tweak something in a script and expect it to go well
let developers do their job, writing bash scripts is something extraordinary for dev team to do, just because - where they expected to apply it? I can imagine "lonely dev startups" situations only, where it may be reasonably needed
Dotnet with all dependencies you will get in how much time? In like 6 minutes including all the preparations? So the difference between "already there" and dotnet - is 6 minutes. It's hard to imagine a case where this difference matters.
Besides, the trick is knowing what is POSIX compliant and portable, and what isn't. A lot of things will almost work.
Powershell on UNIX is like Perl on Windows. It works, but it's weird and alien. But the same can be said for .NET, really.
Lame joke aside, I only heard "shebang" prior to around that time, then "hashbang" and now I get a mix of it. Google trends indicates "shebang" always dominated.
California, 40yo fwiw
It's "sharp" (i.e. higher tone) because it's a higher-level language compared to C and C++.
I don't know if they still pronounce it that way or not.
Remember, it was originally release +20 years ago (goddamn, I feel old now); recorded video or even audio over the internet were much, much, MUCH rarer then, when "high-speed" speed internet for a lot of people meant a 56K modem.
Back then, most developer's first exposure to C# then was likely in either print form (books or maybe MSDN magazine).
Also got a few of those magazine CDs, in some box.
https://en.wikipedia.org/wiki/Number_sign#Names
It still is, to this day: if you call an automated system such as voicemail, you may be prompted to "press 'pound'". This is really standardized, AFAICT, and no telephone system has told me to "press hash" or "press the 'number' key" [because that's ambiguous]
cks has a history of #! but not an etymology: https://utcc.utoronto.ca/~cks/space/blog/unix/ExecAndShebang...
He links to Wikipedia which documents a good history: https://en.wikipedia.org/wiki/Shebang_(Unix)#History
I was trying to recall what we called it. I used SVR3, so I would've been using "#!/bin/sh" as early as 1990, and even more on SunOS 4 and other Unix servers.
I can't recall having a name for it until "hash-bang" gained currency later. We knew it was activated by the magic(5) kernel interpretations. I often called "#" as "pound" from the telephone usage, and I recall being tempted to verbalize it in C64 BASIC programming, or shell comment characters, but knowing it was not the same.
"The whole shebang" is a Civil-War-era American idiom that survived with my grandparents, so I was familiar with that meaning. And not really paying attention to Ricky Martin's discography.
Wikipedia says that Larry Wall used it in 1989. I was a fervent follower of Larry Wall in the mid-90s and Perl was my #1 scripting language. If anyone would coin and/or popularize a term like that, it's Just Another Perl Hacker,
Likewise, "bang" came from the "bang path" of UUCP email addresses, or it stood for "not" in C programming, and so "#!/bin/sh" was ambiguously nameless for me, perhaps for a decade.
Come to think of it, vi and vim have a command "!" where you can filter your text through a shell command, or "shell out" from other programs. This is the semantic that makes sense for hash-bangs, but which came first?
"Bang" was in common use by computer users around 1970 when I was working at Tymshare. On the SDS/XDS Sigma 7, there was a command you could use from a Teletype to send a message to the system operator on their Teletype in the computer room. I may have this detail wrong, but I seem to recall that it included your username as a prefix, maybe like this:
GEARY: CAN YOU LOAD TAPE XYZ FOR ME?
What I do remember clearly is that there were also messages originated by the OS itself, and those began with "!!", which we pronounced "bang bang". Because who would ever want to say "exclamation point exclamation point"?The reason this is vivid in my mind is that I eventually found the low-level system call to let me send "system" messages myself. So I used it to prank the operator once in a while with this message:
!! UNDETECTABLE ERROR
I was proud of calling it an "undetectable" error. If it was undetectable, how did the OS detect it?The joke didn’t land, sadly.
Although it's old and its dependencies are old, it doesn't have a dependency on cargo (it spawns cargo as a subprocess instead of via cargo API directly), so it might still work fine with latest toolchain. I haven't tried myself.