cons from Slant about bash : )) One of the most dangerous languages around What it is mostly used for are file system operations. Guess what it is bad at? Operating on files. It automatically splits and carries out filename expansion on every single string resulting from variable expansion and command substitution unless quoted, by default on whitespace, whilst spaces are very common in filenames. Before that, it even does pathname expansion, so woe to anywone who does not want to actually operate on files, but has a globbing metacharacter stored anywhere in a variable. This means what you store in a variable is not going to be what will ACTUALLY be accessed. If an empty variable is unquoted, it disappears completely due to word splitting, sometimes leading to applications signalling a missing parameter at a wrong position. If quoted however, said variables cannot be iterated over in a loop, no matter what character one uses for word splitting. If you use any globbing pattern with a command, be sure to use -- after the option arguments or if none are present, before starting the pattern with a mandatory ./ Otherwise, another Bash script run gone wrong or a hacker can create files named like an option ("-f", for instance) and your program will happily accept it as such, if it results from globbing. For interactive use, it is convenient. For programming, it is a no-go.
Protip: minimise the terminal to make it go faster. Also you're wrong, powershell is one of the better shells ever written. Way better than bash, and i'll die on this hill. MS are too retarded to use it properly and their terminal is basically hitler and satan.
Bash is actually resonably fast if you stay in the shell. When you use externals a lot (grep, sed, awk, head, tail...) Bash is SLOW.... Also, The Regex operator in bash is =~ try it. I have been rewriting a lot of scripts to use this instead of grep, sed, awk etc. Especially my web scrapers. It understands Extended Regular Expressions, ERE and creates an array with the matches it finds. Have fun and always keep learning.
You said it yourself “when you use externals...” Do you think Bash is slow when the cause of the slow down is a bunch of external processes that Bash forks out? Bash is just a glue.
Bash is glue + function, You would be amazed at what it is capable of doing on it's own. stuff you would do with tr, sed, grep, head, tail, wc..... much of this can be done in bash. For me Web scrapping is so easy in bash. working with json or xml is easy. on and on...
@@magno5157 That's my point, Stay in the shell. The thing is, to do one or two function? Fine use an external. If it's repetitive? find a way to do it with shell internals.
For those wondering, there are benchmarks in stackoverflow and dash takes about half or even a quarter of the time to run. Not huge in my opinion but a nice way to speed things up. Anyway if you want speed it seems like trying to stick with awk whenever possible is best
Hi, mksh developer here ☻ thanks for the mention! Note that mksh does implement a few bashisms (just as bash implements things like [[…]] which are kshisms), but not this one; diff between two processes is actually the only time I temporarily switch to GNU bash myself. For better performance, link mksh statically (beats dynamically-linked dash in speed even!) and add the optional printf builtin, which you’re going to be using a lot in POSIX scripts unless you actually check for the ksh print builtin first and use that if present. Note that the printf builtin does not and cannot have floating point (%f) though…
It's a very important topic. One thing you may want to look at moving forward, is that while sh is always going to be in /bin/sh ; bash might not be. In BSDs you'll find bash in /usr/local/bin/bash There is an easy solution, that is actually best practice for cross-platform compliance, is to use the `env` command. `env` returns the value of the binary in your environment. It is always in /usr/bin/env - see below for how to use it in a bash script, that will work, cross platform. :) #!/usr/bin/env bash
Even sh isn't sure to be in /bin/sh, Linux is moving to unified directories and both /bin and /sbin and a couple others are depricated. They have been symbolic links to /usr/... in most of the mainstream distros for a few years. (The only reason for the original /bin /usr/bin split was physical device space limitations on the PDP-7 and 11 used to develop Unix.)
Thanks for making this video. Especially thanks for not using a giant mostly empty frame to sow what amounts to text. So many people make those and they’re damn hard to watch without full screen on a desktop. This was watchable ON MY PHONE!!! Awesome.
Mainly, most optimizations is done in the design level and not in the language one chooses to write. For example, intead of reading all the file just to see the first one, you could just read the first. It could be done chooseing wisely the commands we would run. The optmization he is telling us to do is nearly negligible (in the execution time), and sounds like choosing C++ instead of python to write scripts.
A bloated shell will use more battery life per process because it requires more power so dropping bash might gain someone a little better battery life on their laptops. Sure, it might not be much, but as any system engineer knows the less a cpu has to do, the less power it will use.
Interesting... Been using bash for years haven't really noticed a huge lag.. I'm guilty of using bashisms all over the place. Great video, feeling challenged!
There are two POSIX shells /bin/sh which should be a Bourne shell and /bin/ksh which should be a Korn Shell. ksh is the POSIX extended shell. Many systems do have a ksh type shell as bin/sh but not all and this is less common UNIX unix. bash started out as a ksh clone, it's gotten quite fat and slow over the years though.
Thanks for that insight Luke. But how slow is slow? Could you do a example benchmark for differnt scripts? If it´s only a few ms every now and then I don´t see the caveat.
@@gregoriodia I know a pretty good way of optimizing your code. =) $ cat to1m_old.sh i=0 END=1000000 while [ $i -le $END ] do i=$((i + 1)) done $ time bash to1m_old.sh real 0m2,990s user 0m2,986s sys 0m0,005s $ cat to1m_new.sh exit 0 $ time bash to1m_new.sh real 0m0,003s user 0m0,000s sys 0m0,003s Most of the optimization is done in the design level and not in the shell you choose to run.
Hi Luke, great video! I've only got one question: why did you show mksh at first and then you showed that you have /bin/sh symlinked to dash? Is there any reason you symlinked /bin/sh to dash instead of mksh? Thank you in advance!
dash is faster, while mksh tries to be an interactive shell. For example mksh has features like a config file and other things, while dash doesn't, so while it's faster, it's not necessarily an option for using interactively.
@@LukeSmithxyz mksh tries to be primarily a great scripting language that can also be used interactively well, though without the bling-bling. Then comes POSIX compliance, then comes compatibility to other shells. The performance of mksh and dash is pretty close (dash *is* somewhat simpler), and mksh-static will beat dash any day ☻ Startup files are not read for scripts, only interactively (and they’re in the appropriate if branch so this doesn’t slow dow at all).
you might take this as a joke, but I actually have a little 13 inch laptop, with ONLY tmux on it, and NO XServer which actually satisfies my twisted needs and perverted perfectionism
BusyBox which is used in rescue shell, on embedded devices, in Alpine for containers or OpenWrt for routers actually uses Dash but modified and has more bashisms like $RANDMON variable. So you may see a /bin/sh scripts that actually have bashisms and that's fine. You can run them with #/bin/busybox sh
The title of this video really does not give the content justice. I learned a lot of good information that I'll be using in my everyday script writing, but the title did not alert me to the fact this would be informing me about why it's important to write POSIX-compliant scripts.
use (d)ash for about 80% of time it works fine ;P 10% you have to work around bashisms, and other 10% is **insert problem here** for some reason I remember it having some tiny enhancements, without finding any source right now... I'd really love a posix version of () as those are SUPER nice and hackable...you can do `echo "hello there >(sed s/hello/goodbye/) >(tee -a /tmp/log) >(xargs -- ls -lha) >(xargs|cd)` etc etc...
dunno about android, but FreeBSD, OpenBSD and Nix come to mind which don't have /bin/bash but have /usr/bin/env. it also gives user more control over which bash is going to be used for the script, in case there's more than one, as it gets one from the $PATH
All of us bash fans should not argue if it's slow or not. Fact is bash is slow. There is also other thing to consider: does that really matter? I mean shell should be feature rich and comfortable to use. Dash is just fast. Bash makes your life much easier. Just use whatever feels best for you.
POSIX is the de-facto standard for unix-like systems (like linux or BSD). When making programs and scripts that are POSIX compliant you assure that users of different system cofigurations can run them on their system.
BenRangel Just like POSIX Shell having many implementations such as Bash, ZSH, Yash, etc, awk also has different implementations. Gawk is one of them and it’s probably very common and it contains extensions that are not specified by POSIX. There are many programs standardised by POSIX and still contain many extensions not specified by the standard.
The tradeoff of slower execution is rarely a problem, and all of the distros I'm currently using have Bash installed by default, so I'll take the bloat (until something better comes along).
In any case, shells are kind of not all that different from each other. Even the much loved zsh is just a mishmash of POSIX stuff and non-portable bells and whistles. No revolution happening in shells yet.
I tried switching from bash to dash, but it broke a bunch of the Manjaro i3 scripts. Not sure I want to deal with fixing them. But the idea of this video is cool.
very impressive shell familiarity ! do you have any opinions on setting the firrst-script-line "hash-bang" to /usr/bin/env instead of hardcoding a path to the interpreter ?
I follow your videos always with great interest and I got never dissapointed. But this piece of knowledge you share in this video is pure gold, hands down. You, sir, really know your business. Thank you so much for sharing! (despite so many ever-appearing fools in the comments :facepalm:)
/bin/sh is owned by the bash pacman package (pacman -Qo /bin/sh). This means that when you update bash, the link to bash will be restored. Your change will be overwritten. There is no correct way to change /bin/sh to anything other than bash because the bash package specifies that it "provides" "sh" and many core packages specify their shell dependency as sh. In other words, it is a design decision of the Arch developers to use bash as the posix sh implementation for the distro and I don't see an option to change this correctly (in a way that won't break after there is a pacman bash update).
To confirm that in its current state it will indeed break with an update, just run 'pacman -S bash; ls -l /bin/sh' and you'll see that the symlink is restored.
@@semenkuzovchikov8150 Nah, tried it, and various combinations with ctrl and plus etc. I guess it's in another file or something. Thanks for replying though!
@@batemanboi9672 Thanks. In my system it was key + shift + u/d. Weird that it's not mentioned somewhere as it's nice and useful thing. Looking at config.h I couldn't find it, but it works now. Also it works on any window in i3, either if it's only window on a workspace in fullscreen mode or if it's floating/non floating in any other setting. I will take a look at Luke's i3 config again. Thanks again for your help.
@@batemanboi9672 But I still have no idea how key+shift+u/d works for me. Nothing in my i3 config suggests that, also nothing in config.h of my suckless build :O
During the "Identifying bashisms" step on the arch wiki, their checkbashisms script that scans /usr/bin/ shows a TON of output . It even identifies some pretty important, more system-level files as containing bashisms, as for example libtool and lsb_release, bzgrep and a ton of TeX related stuff. How did you deal with this? Did you fix them manually? Did you ignore most of the output?
@@rijnder333 I know it's an old comment but my advice is to not change sh to dash or mksh or anything of that nature. Arch is filled to the brim with Bashism with Pacman using them as well. While you are free to change the session shell for sure, the boot shell should be bash in Arch Linux. It's best not to touch that at all. If you are on BSD chances are it will either be ksh or zsh altought bash can be used.
I want to know which are bashisms & which are POSIXisms. Also, I got really annoyed trying to build audacity on TinyCore because its configure ran all scripts in /bin/sh, even a bash script.
When writing posix compliant shell scripts and you want to do process substitution what do you do as an alternative? Write to a temporary file and clean up afterwards?
For the last couple of weeks shellcheck has been receiving an update a few times a day, every day. Don't know what they change internally, but every time I run pacman -Syu there's a new version of shellcheck.
Debian uses Dash because the distro comes from the day when you might have 30 admins all running diff shells and the system needed to get COMPLETELY out of the way of resources etc on dual cpu, not core, dual CPU systems. I know, I was there.
Debian only uses dash because Ubuntu switched to it and some core Ubuntu developers just did it to Debian, despite objection (they actually broke mksh’s functionality to offer itself as /bin/sh and ignored the bugs for years). Either would be fine as /bin/sh, both are comparable in speed (though mksh’s sh is linked statically so even faster), and I’m running all my Debian systems dash-free (link from dash to mksh) even…
If you dont run ancient UNIX in your infrastructure and are 100% Linux shop why writing to POSIX when bash(1) is much more convenient and easy to write to... just saying.
I'm an absolute newbie so please don't crucify me for asking this BUT mac terminal is based on BSD or bash? I'm kinda sure they are not even related, so if you can explain it to me or there are some links to read to understand more about these kinda things, please go ahead!
Press Ctrl+X+E and it will open your editor. If it's not Vim - it's usually nano - add export EDITOR=/usr/bin/vim (or whatever your vim path is) to your .bashrc file
In a command language, everything is assumed to be a literal string unless some special characters indicate otherwise. In a programming language (in which I include Python, Go etc), everything is an expression or statement unless you use special quotes to indicate literal strings. The latter is a pain in a command language. That’s why they’re not designed that way. And that’s why programming languages tend not to be good as command languages.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Why did you even need a shell? Just send your instructions to kernel itself.
any program allowing such operation would be considered a shell ;P
@Joel Silva having a keyboard at all is too bloated, just short out the correct wires instead for input
@@jan_harald typical millennial with your new fangled "plug" technology, real programmers grab a magneto and get cranking!
cons from Slant about bash : ))
One of the most dangerous languages around
What it is mostly used for are file system operations. Guess what it is bad at? Operating on files. It automatically splits and carries out filename expansion on every single string resulting from variable expansion and command substitution unless quoted, by default on whitespace, whilst spaces are very common in filenames. Before that, it even does pathname expansion, so woe to anywone who does not want to actually operate on files, but has a globbing metacharacter stored anywhere in a variable. This means what you store in a variable is not going to be what will ACTUALLY be accessed. If an empty variable is unquoted, it disappears completely due to word splitting, sometimes leading to applications signalling a missing parameter at a wrong position. If quoted however, said variables cannot be iterated over in a loop, no matter what character one uses for word splitting. If you use any globbing pattern with a command, be sure to use -- after the option arguments or if none are present, before starting the pattern with a mandatory ./ Otherwise, another Bash script run gone wrong or a hacker can create files named like an option ("-f", for instance) and your program will happily accept it as such, if it results from globbing. For interactive use, it is convenient. For programming, it is a no-go.
@@jan_harald punch cards are the only real way
the library is bloated with books
Letters are bloated with ink
barnyard I've never felt this defensive over serif fonts in my life.
@barnyard yeah. books should be written with least amount of lines possible to make reading more efficient.
most girls are bloated with hair
The biggest hurdle with writing POSIX shell scripts is that searching for anything shell related will lead you to bash specific answers.
bash is one of the slowest shells?
oh man it feels like lightspeed if you have to use the Windows commandline regularly...
Or wsl bash..
@@gideons6126 oh god I haven't touched that cursed piece of software yet
i used powershell once. boy, i've never felt as much lag as an ls command should. fuck the c# shell.
Protip: minimise the terminal to make it go faster. Also you're wrong, powershell is one of the better shells ever written. Way better than bash, and i'll die on this hill. MS are too retarded to use it properly and their terminal is basically hitler and satan.
@@excitableboy7031 PowerShell-IsGood...... No it's not. It's syntax sucks, it's slow, and nothing uses it.
#!/bin/shhhhhh that's a library!
Too good :')
Dont even bother scripting, just write everything in C
holy C*
Rust is what the cool kids are doing now.
C compiles down to Assembly which is bloated. Write everything in microcode :p
@@wilfridtaylor Yeah, reverse engineer the CPU you have so you can have microcode that only works on a small amount of CPUs...great idea
@@MrSlashStudios the number of different CPUs is too bloated
Shellcheck? That's a Haskell program! You're willing to install Haskell to use this simple tool...but Bash is bloated? ;)
EXPOSED
@Christopher Medlin right
Hello world in haskell compiles to a megabyte-sized binary.
*Read more*
fight! fight! fight! :v :v :v
@@pipoper101 I want to read more you bastard
*crack* Ah, sh. *sips* that was a good shell.
Breathing is bloated.
also overrated af ask fishes they know it.
Bloated with oxygen
Same nitrogen
Living is bloated
The virgin microprocessor vs. the chad abacus.
vim is bloated. use cat >
CAT ABUSE NOT ALLOWED
@@romanhredil3799 then use 'bat'
after 3 years I guess you can now apply for the yearly "cat award" in the unix community
Bash is actually resonably fast if you stay in the shell.
When you use externals a lot (grep, sed, awk, head, tail...) Bash is SLOW....
Also, The Regex operator in bash is =~ try it. I have been rewriting a lot of scripts to use this
instead of grep, sed, awk etc. Especially my web scrapers.
It understands Extended Regular Expressions, ERE and creates an array with the matches it finds.
Have fun and always keep learning.
[neizd@core ~]$ cat to1m.sh
i=0
END=1000000
while [ $i -le $END ]
do
i=$((i + 1))
done
[neizd@core ~]$ time dash to1m.sh
real 0m1.064s
user 0m1.047s
sys 0m0.000s
[neizd@core ~]$ time bash to1m.sh
real 0m3.421s
user 0m3.391s
sys 0m0.016s
[neizd@core ~]$
You said it yourself “when you use externals...” Do you think Bash is slow when the cause of the slow down is a bunch of external processes that Bash forks out? Bash is just a glue.
Bash is glue + function, You would be amazed at what it is capable of doing on it's own.
stuff you would do with tr, sed, grep, head, tail, wc..... much of this can be done in bash.
For me Web scrapping is so easy in bash.
working with json or xml is easy.
on and on...
@@jamesharrison7469 tr, sed, awk, head, tail, wc, xargs, etc they are NOT Bash! So many people confuse these programs as parts of Bash.
@@magno5157 That's my point, Stay in the shell.
The thing is, to do one or two function? Fine use an external.
If it's repetitive? find a way to do it with shell internals.
When you’re so posix compliant you don’t know if the world is real.
For those wondering, there are benchmarks in stackoverflow and dash takes about half or even a quarter of the time to run. Not huge in my opinion but a nice way to speed things up. Anyway if you want speed it seems like trying to stick with awk whenever possible is best
Why not dash for scripts and zsh for user interaction?
@@justadude8716 Bashisms are often too convenient and in regular shell usage, it's unnoticeable
As long as it's mawk or nawk. I understand Gnu Awk (gawk) is a lot slower, which is why Ubuntu installs mawk by default.
Hi, mksh developer here ☻ thanks for the mention!
Note that mksh does implement a few bashisms (just as bash implements things like [[…]] which are kshisms), but not this one; diff between two processes is actually the only time I temporarily switch to GNU bash myself.
For better performance, link mksh statically (beats dynamically-linked dash in speed even!) and add the optional printf builtin, which you’re going to be using a lot in POSIX scripts unless you actually check for the ksh print builtin first and use that if present. Note that the printf builtin does not and cannot have floating point (%f) though…
Good job on mksh!
I will manually enter a valid iee754 floating point binary 32 bits value into the command line and use %f bro. And you cannot stop me
It's a very important topic. One thing you may want to look at moving forward, is that while sh is always going to be in /bin/sh ; bash might not be.
In BSDs you'll find bash in /usr/local/bin/bash
There is an easy solution, that is actually best practice for cross-platform compliance, is to use the `env` command.
`env` returns the value of the binary in your environment. It is always in /usr/bin/env - see below for how to use it in a bash script, that will work, cross platform. :)
#!/usr/bin/env bash
Even sh isn't sure to be in /bin/sh, Linux is moving to unified directories and both /bin and /sbin and a couple others are depricated. They have been symbolic links to /usr/... in most of the mainstream distros for a few years. (The only reason for the original /bin /usr/bin split was physical device space limitations on the PDP-7 and 11 used to develop Unix.)
Thanks for making this video. Especially thanks for not using a giant mostly empty frame to sow what amounts to text. So many people make those and they’re damn hard to watch without full screen on a desktop. This was watchable ON MY PHONE!!! Awesome.
Yeah yeah bash is slow. But who writes CPU-bound scripts in bash anyways? Process substitution is a killer feature.
I'd like these word to sing themselves
Mainly, most optimizations is done in the design level and not in the language one chooses to write. For example, intead of reading all the file just to see the first one, you could just read the first. It could be done chooseing wisely the commands we would run. The optmization he is telling us to do is nearly negligible (in the execution time), and sounds like choosing C++ instead of python to write scripts.
@@MrRenanwill Platform specific optimizations can add up for frequently executed programs.
A bloated shell will use more battery life per process because it requires more power so dropping bash might gain someone a little better battery life on their laptops. Sure, it might not be much, but as any system engineer knows the less a cpu has to do, the less power it will use.
This is the first time ever I've heard Bash or a shell for that matter is slow. You had my curiosity, now you have my attention.
3:37: Process substitution isn't (just) a bashism, it's a Korn shell innovation; bash just copied it from ksh88 or ksh93 (and enabled it by default).
Interesting... Been using bash for years haven't really noticed a huge lag.. I'm guilty of using bashisms all over the place. Great video, feeling challenged!
It is popular for a reason.
1:20 an elaborate way to say "I use arch btw"
lol
"Don't get it twisted" - Linguist and Nix User, 2019
There are two POSIX shells /bin/sh which should be a Bourne shell and /bin/ksh which should be a Korn Shell. ksh is the POSIX extended shell. Many systems do have a ksh type shell as bin/sh but not all and this is less common UNIX unix. bash started out as a ksh clone, it's gotten quite fat and slow over the years though.
Everything I don't like is bloated
A youtuber's guide to making titles
yknow... except systemd
lmao, as bloated as systemd is its not nearly as bad as that intel pxe shit on old thinkpads.
If you're having to worry about performance while using bash, then you shouldn't be using bash.
I like that you chose to make this tutorial at a library . i feel like stepping through the screen to peruse the shelves
Shhh be quiet. This is a library. I'm trying to study...
I hear TempleOS is good. No bloat there.
Thanks for that insight Luke. But how slow is slow? Could you do a example benchmark for differnt scripts? If it´s only a few ms every now and then I don´t see the caveat.
[neizd@core ~]$ cat to1m.sh
i=0
END=1000000
while [ $i -le $END ]
do
i=$((i + 1))
done
[neizd@core ~]$ time dash to1m.sh
real 0m1.064s
user 0m1.047s
sys 0m0.000s
[neizd@core ~]$ time bash to1m.sh
real 0m3.421s
user 0m3.391s
sys 0m0.016s
[neizd@core ~]$
@@gregoriodia I know a pretty good way of optimizing your code. =)
$ cat to1m_old.sh
i=0
END=1000000
while [ $i -le $END ]
do
i=$((i + 1))
done
$ time bash to1m_old.sh
real 0m2,990s
user 0m2,986s
sys 0m0,005s
$ cat to1m_new.sh
exit 0
$ time bash to1m_new.sh
real 0m0,003s
user 0m0,000s
sys 0m0,003s
Most of the optimization is done in the design level and not in the shell you choose to run.
Hi Luke, great video! I've only got one question: why did you show mksh at first and then you showed that you have /bin/sh symlinked to dash? Is there any reason you symlinked /bin/sh to dash instead of mksh?
Thank you in advance!
dash is faster, while mksh tries to be an interactive shell. For example mksh has features like a config file and other things, while dash doesn't, so while it's faster, it's not necessarily an option for using interactively.
@@LukeSmithxyz thank you! I probably missed that part in the video, in case you explained it already :)
@@LukeSmithxyz mksh tries to be primarily a great scripting language that can also be used interactively well, though without the bling-bling. Then comes POSIX compliance, then comes compatibility to other shells.
The performance of mksh and dash is pretty close (dash *is* somewhat simpler), and mksh-static will beat dash any day ☻
Startup files are not read for scripts, only interactively (and they’re in the appropriate if branch so this doesn’t slow dow at all).
What's next, terminal emulators are bloat; be one with the tty?
SimGunther Computers are bloat!
@@AnonymousUser77254 CPUs and their ISAs are bloat
SimGunther hard drives are definitely bloat. My commodore PET doesn't have a hard drive.
xterm is pretty big though, last i checked. There are alternatives to xterm.
you might take this as a joke, but I actually have a little 13 inch laptop, with ONLY tmux on it, and NO XServer
which actually satisfies my twisted needs and perverted perfectionism
BusyBox which is used in rescue shell, on embedded devices, in Alpine for containers or OpenWrt for routers actually uses Dash but modified and has more bashisms like $RANDMON variable.
So you may see a /bin/sh scripts that actually have bashisms and that's fine.
You can run them with #/bin/busybox sh
"Bash is Bloated!"
> uses bash
🤔
You REALLY missed the point :facepalm:
The title of this video really does not give the content justice. I learned a lot of good information that I'll be using in my everyday script writing, but the title did not alert me to the fact this would be informing me about why it's important to write POSIX-compliant scripts.
I just want to say thank you Luke. I've learnt a great deal from you, you've really upped my unix game
Where did you learn all this stuff? Could you please link some online resources here, or on your website for people who wish to do it as well?
my man has maxed out 'tech lord', and 'presentation' skills.
Windows command line (Batch/CMD) > Bash
use (d)ash
for about 80% of time it works fine ;P
10% you have to work around bashisms, and other 10% is **insert problem here**
for some reason I remember it having some tiny enhancements, without finding any source right now...
I'd really love a posix version of () as those are SUPER nice and hackable...you can do `echo "hello there >(sed s/hello/goodbye/) >(tee -a /tmp/log) >(xargs -- ls -lha) >(xargs|cd)` etc etc...
Of course, mksh isn’t narrowly POSIX-compliant, it’s an implementation of ksh. And IIRC the author wants to implement process substitution as well.
Yeah, when I find a way to do that that doesn’t slow down things too much or breaks them, and is reasonably portable.
You can never please everyone and although I don't agree here and there, I'm always learning something! Keep doing those videos!!! Thanks!
So... no it won't run shell scripts as bash scripts if /bin/sh is linked to bash. Bash will run with strict POSIX compliance if called as sh
is luke really at the library or is he using a green screen? if he's in a legit library that is ultimate chad mode
I think it would be better to put #!/usr/bin/env bash instead of #!/bin/bash for more portability
Which Linux-compatible systems don’t have /bin/bash?
@@lawrencedoliveiro9104 Android
@@brlin Would /usr/bin/env bash work there?
dunno about android, but FreeBSD, OpenBSD and Nix come to mind which don't have /bin/bash but have /usr/bin/env. it also gives user more control over which bash is going to be used for the script, in case there's more than one, as it gets one from the $PATH
I'm glad I write my scripts in python.
I use zsh and that one is even more bloated than bash, I have a feeling.
All of us bash fans should not argue if it's slow or not. Fact is bash is slow.
There is also other thing to consider: does that really matter? I mean shell should be feature rich and comfortable to use.
Dash is just fast.
Bash makes your life much easier.
Just use whatever feels best for you.
Nice subliminal message with the off grid thing.
What is POSIX and why should I care?
POSIX is the de-facto standard for unix-like systems (like linux or BSD). When making programs and scripts that are POSIX compliant you assure that users of different system cofigurations can run them on their system.
BenRangel Just like POSIX Shell having many implementations such as Bash, ZSH, Yash, etc, awk also has different implementations. Gawk is one of them and it’s probably very common and it contains extensions that are not specified by POSIX. There are many programs standardised by POSIX and still contain many extensions not specified by the standard.
If you're using an interactive shell there's no reason to care - just use fish. This isn't 1980.
Serious question: What is the font you're using in your terminal? Thanks!
I don't have a definite answer, but I think Luke mentioned Inconsolata, or maybe Fira Mono/Fira Code before
It does look like Inconsolata to me though
bash is slow - two questions - why and by how much?
I use systemd bash, systemd kernel, systemd gcc and systemd graphical environment on Redhat Systemd/Systemd os.
I use MS Windows 10. (Basszus ezt a csávót magyarok is nézik?)
@@ezengondolkozom3700 I don't use hungarian. I use en_US.UTF-8.
@@Zoltan_Gyarmathi *cries in UTF-16
The tradeoff of slower execution is rarely a problem, and all of the distros I'm currently using have Bash installed by default, so I'll take the bloat (until something better comes along).
In any case, shells are kind of not all that different from each other. Even the much loved zsh is just a mishmash of POSIX stuff and non-portable bells and whistles. No revolution happening in shells yet.
@@SisypheanRoller nushell is trying to do something different
I tried switching from bash to dash, but it broke a bunch of the Manjaro i3 scripts. Not sure I want to deal with fixing them. But the idea of this video is cool.
very impressive shell familiarity ! do you have any opinions on setting the firrst-script-line "hash-bang" to /usr/bin/env instead of hardcoding a path to the interpreter ?
I follow your videos always with great interest and I got never dissapointed. But this piece of knowledge you share in this video is pure gold, hands down. You, sir, really know your business. Thank you so much for sharing! (despite so many ever-appearing fools in the comments :facepalm:)
*shuffles cards*... bash is bloated
Life is bloated!
The link on Debian by default is dash.
mksh may not have process substitution but ksh93 does. I suppose mksh is more of a ksh-88 clone?
/bin/sh is owned by the bash pacman package (pacman -Qo /bin/sh). This means that when you update bash, the link to bash will be restored. Your change will be overwritten. There is no correct way to change /bin/sh to anything other than bash because the bash package specifies that it "provides" "sh" and many core packages specify their shell dependency as sh. In other words, it is a design decision of the Arch developers to use bash as the posix sh implementation for the distro and I don't see an option to change this correctly (in a way that won't break after there is a pacman bash update).
Use a pacman hook. Check the Arch Wiki for dash.
To confirm that in its current state it will indeed break with an update, just run 'pacman -S bash; ls -l /bin/sh' and you'll see that the symlink is restored.
As someone who uses ZSH, I cannot relate
Nobody:
Luke Smith: Don't get it twisted...
I guess you can say it got *bashed* pretty hard.
6:40 - LF ?
linux kernel is bloated
Mkay?
shellcheck is nice
why is he recording a video in a library?
i stick to bash , nice and steady for simple launchers and compares
posix compl. is for repo work
Why is posix compliance important?
Is that suckless terminal? I'm trying to find the shortcut for resizing on the fly (I'm using your build), but I can't find it anywhere.
@@semenkuzovchikov8150 Nah, tried it, and various combinations with ctrl and plus etc. I guess it's in another file or something. Thanks for replying though!
kmg its Windows key + Shift + u/i/o/p
This setting is in the i3 config, also it must be in windowed mode it if the only open program, using windows + shift + space
@@batemanboi9672 Thanks. In my system it was key + shift + u/d. Weird that it's not mentioned somewhere as it's nice and useful thing. Looking at config.h I couldn't find it, but it works now. Also it works on any window in i3, either if it's only window on a workspace in fullscreen mode or if it's floating/non floating in any other setting. I will take a look at Luke's i3 config again. Thanks again for your help.
@@batemanboi9672 But I still have no idea how key+shift+u/d works for me. Nothing in my i3 config suggests that, also nothing in config.h of my suckless build :O
During the "Identifying bashisms" step on the arch wiki, their checkbashisms script that scans /usr/bin/ shows a TON of output . It even identifies some pretty important, more system-level files as containing bashisms, as for example libtool and lsb_release, bzgrep and a ton of TeX related stuff. How did you deal with this? Did you fix them manually? Did you ignore most of the output?
btw I use arch
@@rijnder333 I know it's an old comment but my advice is to not change sh to dash or mksh or anything of that nature. Arch is filled to the brim with Bashism with Pacman using them as well. While you are free to change the session shell for sure, the boot shell should be bash in Arch Linux. It's best not to touch that at all. If you are on BSD chances are it will either be ksh or zsh altought bash can be used.
6:43 Which file manager is that? Ranger?
Yep
Possics compliant shell? Whats it say?
But what if some scripts in /usr/bin have bashisms? Should I point each one to /bin/bash?
I want to know which are bashisms & which are POSIXisms. Also, I got really annoyed trying to build audacity on TinyCore because its configure ran all scripts in /bin/sh, even a bash script.
When writing posix compliant shell scripts and you want to do process substitution what do you do as an alternative? Write to a temporary file and clean up afterwards?
I heard named pipes are suitable for the job.
I ran ls-l /bin/sh on my Ubuntu I run on my machine, and yes, Ubuntu comes with dash by default.
Sir, are your scripts such as tools/shortcuts available for download and use?
can you post some benchmarks from popular shells like bash fish zsh and others?
At this point what's not bloat?
Computers are bloat
Man, how come you weren't kicked out of the library?
Maybe it's a wallpaper
@@xGOKOPx no way!
For anyone using syntastic in vim: it integrates nicely with shellcheck and saved me so many hours already. Good recommendation Luke!
That project seems to be out of maintenance now :(
@@martiananomaly Which one?
For the last couple of weeks shellcheck has been receiving an update a few times a day, every day. Don't know what they change internally, but every time I run pacman -Syu there's a new version of shellcheck.
It's just to make me happy. I love installing updates. It feels good.
So when is it appropriate to use the dot "sh" suffix?
Filenames don't ever really matter, only what you mark it as on the first line. I nearly never had extentions to my scripts.
any time you want, .sh is just shell script... to a windows person ;)
#!/bin/sh or #!/bin/bash is the key...
Good info. My Ubuntu 18 is linked to dash. I don't know if that's standard of zsh did that.
bash [[ ]] is better than test([ ]) since it doesn't spawn new process and most probably is faster
Debian uses Dash because the distro comes from the day when you might have 30 admins all running diff shells and the system needed to get COMPLETELY out of the way of resources etc on dual cpu, not core, dual CPU systems. I know, I was there.
Debian only uses dash because Ubuntu switched to it and some core Ubuntu developers just did it to Debian, despite objection (they actually broke mksh’s functionality to offer itself as /bin/sh and ignored the bugs for years). Either would be fine as /bin/sh, both are comparable in speed (though mksh’s sh is linked statically so even faster), and I’m running all my Debian systems dash-free (link from dash to mksh) even…
Note that I managed to switch Android from ash to mksh as /system/bin/sh…
Why is your computer named "core" ?
if you use the feature then why you call it bloat, if you were serious in video title?
If you dont run ancient UNIX in your infrastructure and are 100% Linux shop why writing to POSIX when bash(1) is much more convenient and easy to write to... just saying.
Green screen library?
I'm an absolute newbie so please don't crucify me for asking this BUT mac terminal is based on BSD or bash?
I'm kinda sure they are not even related, so if you can explain it to me or there are some links to read to understand more about these kinda things, please go ahead!
What Bash is slow now???
What next? C is slow???
Why not just do everything in machine code?
Machine code is bloated. Synthesizable VHDL code is bloated. CMOS gates are bloated. Transistors are bloated. QM is damn bloated...
Just use abacus, that doesn't seem bloated that much...
@@matemana1991 wow! I really didn't expect the difference to be that large
How he edit the terminal input like in vim??
Press Ctrl+X+E and it will open your editor. If it's not Vim - it's usually nano - add export EDITOR=/usr/bin/vim (or whatever your vim path is) to your .bashrc file
Why did you stopped using fish?
I never used fish.
@@LukeSmithxyz I thought you did at some point. I watched a few videos on your channel talking about fish, but I guess it was just a review.
What about using python or Go as your scripting language?
In a command language, everything is assumed to be a literal string unless some special characters indicate otherwise. In a programming language (in which I include Python, Go etc), everything is an expression or statement unless you use special quotes to indicate literal strings.
The latter is a pain in a command language. That’s why they’re not designed that way. And that’s why programming languages tend not to be good as command languages.