echo is broken: a follow-up video

[@soranuareane]

That video was quite informative. As someone who uses bash daily, and as part of my job, this certainly made me pause to reconsider how I design my scripts.

[@necroowl3953]

By moving over to a programming language

[@thezipcreator]

@@necroowl3953 bash technically is a programming language

[@davidjohnston4240]

@@thezipcreator But is it turing complete if it can't output -n?

[@thezipcreator]

@@davidjohnston4240 turing complete has nothing to do with output. it just means that, with unlimited memory, it can perform any possible operation.

[@jimschneider799]

We need more of this kind of clear, thoughtful analysis in technical videos.

[@computopia]

Glad to see another video, but I hope you haven't given up on making ZX Spectrum AoC videos… FWIW, I did the “echo -ne '\055n'” solution when I watched your previous bash video. BTW, if you want more shell silliness, you should check out the fact that GNU true (/bin/true) is the only version of true on any Unix-like system that can sometimes return false. It has one job, and fails. I'll leave you to work out how to make it return false.

[@RandomGeometryDashStuff]

hint: help

[@aaronjamt]

Update: yes it does, holy crap I figured it out... that is evil

[@jammin023]

I enjoy the fact that even after nearly 30 years of using Linux, someone like you can come along with important basic knowledge that I was completely unaware of. Also thanks for introducing me to fish, I love it.

[@rubenpriority725]

Excellent follow-up. Would like to see more from you, so I'm commenting for the algorithm.

[@miguelguthridge]

A spectacular video as always! I'm so glad I found this channel

[@dafman4]

A fun follow-up to an interesting issue that I wasn't aware of with bash. Honestly though, it''s just nice to have my love for fish somewhat validated. Also, to find another fish user :)

[@yash1152]

6:53 type is a nice shell builtin command too. TIL

[@toriikyuu]

6:09 I'd love to see how you can make animations in blender from a custom description of them If you're not ready to release any version to github which I understand, could you point me to somewhere that'll teach me how to do thing like that Since I'm typing a comment; Great video! Not only a journey to //\\/\\\\, but also a lesson in making rules (for challenges and in general)

[@ZipplyZane]

Another loophole that occurs to me would be to make it output an actual dash character rather than a hyphen. Either an emdash or endash would work.

[@capability-snob]

Not super important for this subject, but If we didn't want our comments immortalised, we probably wouldn't have made them and put them on the internet. It's funny how attribution is only important if the person making the comment is already well-known. Still, great to see the follow up on this.

[@minnerlas1730]

The reason why zipgrep works with dash as /bin/sh and not dash is that dash is pretty much an implementation of posix Bourne shell, while bash has a bunch of extensions and it's posix compatibility mode is lacking. Setting bash as /bin/sh is a big mistake a lot of distros do if you care about script portability

[@Trainz2950]

fish + kitty supremacy!!!!!

[@pdelong42]

If you don't have the "xxd" tool, then the "-A" flag to "cat" will expose the "\b" trick as well, like so: $ echo -en ' \b-n' | cat -A

[@pdelong42]

Note that this is a GNU-only option (e.g., not present on macOS)

[@leyasep5919]

After the Obfuscated C Coding Contest, now comes the Obfuscated Bash 😀

[@piqu69]

i use alacritty and nushell bc they work on linux and windows

[@HUEHUEUHEPony]

... that blender terminal.... release it 🔫

[@UltimatePerfection]

Videos are fine and dandy, but if you're a coder why not fix the bash echo and PR it?

[@computingthedetails]

thanks for the comment :) this is an intereting question There's arguments for and against making such a change. The video shows the advantages of making it consistent with other programs, and allowing use of "--" to ignore further options, for example. On the other hand, while it is totally possible to change the behaviour of bash's echo like this, it would be a change of behaviour that might break compatibility with existing bash programs. To change this now would probably result in so many breakages that it wouldn't be worthwhile. Legacy code is stable and battle-tested. With bash being a component that so much legacy code depends on, every breaking change made in bash is hugely disruptive. Another option would be to add in another command, with a different name, which behaves like echo but without this flaw. But then you could argue that printf is already a suitable command to fill this need. Anyway, the TL;DR version is: It's probably too disruptive to fix this now, but it's up to the bash maintainers to consider fixes if they want to.

[@UltimatePerfection]

@@computingthedetails Maybe add a command line switch that enables "correct" behavior? That way by default it would still be "broken" but if you need it to work right, add that parameter to the echo call?

[@apmcd47]

@@UltimatePerfection But which is the correct behaviour? /bin/echo has the same behaviour and is part of the Gnu Core Utils, from which one can surmise that, as far as the FSF is concerned, bash has it correct and any shell that implements it differently has a broken echo. And why add yet another option when the easiest solution is don't use echo in your scripts - use printf instead.

[@your-mom-irl]

@@apmcd47 the POSIX correct behavior is to ignore every single option, and -- too. Look it up. So one way or another bash and gnu echo are already breaking POSIX compatibility, Interestingly GNUs echo was written by the same guy who mantains bash, Chet Ramey. I guess sending a mail to the bash mailing list can't hurt.

[@apmcd47]

@@your-mom-irl And by definition all other implementations of echo? Having just read the posix echo man page I see that nearly all the other implementations of echo are wrong because they treat "--" as an argument. But is it worth fixing this bug? (1) fixing this bug could break something written 20 years ago! (2) If you are programming in a shell the current wisdom is use printf instead of echo!

[@anon_y_mousse]

Kind of makes me sad to think that there are long-term Linux users who didn't know that `echo` was also a `bash` built-in. Although, it sounds like a BS challenge to say you can't do the most obvious thing that everyone who expects some consistent behavior from `echo` should do, which is to just use `/bin/echo`. Also, I'm pretty sure most POSIX conformant programs use a double dash to indicate the end of argument processing as the single dash is commonly used for informing the program that standard input is the file to read. Sure, exceptions such as `echo` exist, but it doesn't read input from files or write output to files. If you were to complain about `ffmpeg`'s non-conformance with command line options, then I'd agree.

[@xurtis]

Yeah, your system installing a /bin/sh that doesn’t conform to POSIX shell wold be a violation. Zipgrep is fine, it’s only depending on guaranteed behaviour of POSIX; it’s just that most Linux distributions are not POSIX compliant in particularly dumb ways like this. This is 100% a failure of you Linux distro to provide a shell that conforms to any agreed standard at an agreed path; without that there’s no way to make a script that is both portable across POSIX implementations and guaranteed to work on your particular distro.