They genuinely believe they have a God given right to break the speed limit


This entry was edited (29 minutes ago)

Bash v5.3 Released! New features and syntax in the latest version of the Bash Shell. by You Suck at Programming on YouTube [17:10min]


Watch on SkipVid platform, alternative to YouTube client watching YouTube videos indirectly, but without ads: skipvids.com/?v=-cTsFt-j7rk


I just found this creator who is super excited about the new Bash version. He goes through some aspects of the new changes and features. There is something funny about a guy getting so excited about a new Bash version, that I wanted to share it because of that. 😁

Also its nice to see the changes in action and have an explanation from someone who (seemingly) knows what he is doing.

Video (partial) description:


Source Code: github.com/bahamas10/bash-changes

$ whoami
Yo what's up everyone my name's dave and you suck at programming! Connect with me on my socials below and if you're reading this you're legally required to subscribe to my channel.

$ cat source-code
The source code for my YSAP series (or related videos) is available for free under the MIT License on GitHub:
Source Code → github.com/bahamas10/ysap

in reply to thingsiplay

Honestly this made me really sad that we're stuck with this archaic, awful language as a primary way of programmatically interacting with our computers. And I don't mean to say anybody has done anything wrong here - sh and bash were revolutionary and amazing for their respective times, and maintainers who are keeping bash alive now are heroes who deserve praise. However, many decisions made when sh was originally developed turned out to be footguns, still creating bugs today (despite shellcheck et al).

nushell is somewhat promising but flawed (because it has to be built on the same system interfaces as sh, after all). The most annoying is that there's no facilities for setting any metadata on data streams (in particular there's no way to set the format of the data) so everything has to be marshalled manually, which would be OK for a proper programming language but really annoying for a shell. At least it fixes most of the quoting, escaping, interpolation, substition etc awfulness, and allows for manipulating data in a more structured way.

I really don't know if it's even possible to make a language that would be a good convenient shell and at the same time not prone to bugs which are easily noticeable in other languages. I hope that something like this becomes a reality at some point.

This entry was edited (1 hour ago)
in reply to balsoft

If you want to do a Bash like management and programming, that is not dramatically different but fixes some irritations, then Fish is an alternative. Obviously it will not fix all issues, but there is no paradigm shift in handling streams. nushell is dramatically different and at that point, I would rather use a programming language to do the stuff. Speaking of programming language, there is also Xonsh (basically Python+Bash like combination as a system shell).

All these alternatives have a singular big flaw to me: they are not the standard tools on the system, which defeats the purpose of a system shell to me. In the end, without changing the core system that these shells are built on, I don't think its possible to make a really well made language that interoperates on system level like a shell does at the moment.

That's the reason why I got a bit more into Bash to understand some flaws, to understand how to use regexes inside Bash and variable substitutions and a few other concepts that are very useful to know. But man... there are so many traps... like looping over a wildcard for files (such as for file in *.txt) and if the wildcard does not match, then the loop consists of the wildcard as a literal word as if "*.txt" was a filename. What a stupid idea. There is an option to change that, but that's the issue. The language is filled with traps and optional options and you have to know all of them.

Edit: Added example code why default behavior sucks:

$ for file in *.ABCD; do echo "${file}"; done
*.ABCD
shopt -s nullglob
$ for file in *.ABCD; do echo "${file}"; done
This entry was edited (33 minutes ago)

Any ideas for transporting variables in chroot bash script?


Hello, iam in the making of artix install script. I start with setting variables in dialog like bootloader="refind" and etc. but when i do artix-chroot into chroot.sh script variables are gone.

right now i have something like this:

cp ${pwd}execution/chroot.sh /mnt/mnt &&
            USER="$USER" USER_PASSWORD1="$USER_PASSWORD1" USER_PASSWORD2="$USER_PASSWORD2"\
            ROOT_PASSWORD1="$ROOT_PASSWORD1" ROOT_PASSWORD2="$ROOT_PASSWORD2"\
            BOOTLOADER="$BOOTLOADER" SUPERUSER="$SUPERUSER" HOSTNAME="$HOSTNAME"\
            LOCALE="$LOCALE" ENCRYPTION="$ENCRYPTION" ROOT="$ROOT" ESP="$ESP"\
            KERNEL="$KERNEL" UCODE="$UCODE"
        artix-chroot /mnt bash -c '/mnt/chroot.sh && execute_root' 

But it does not really work, tried also some things like:
# create array of variables to pass to part 2
var_export=($formfactor $threadsminusone $gpu $boot $disk0 $username $userpassword $timezone $swap $intel_vaapi_driver $res_x $res_y_half)

# initiate part 2
mount --bind /root/artix-install-script /mnt/mnt
artix-chroot /mnt /mnt/chrootInstall.sh "${var_export[@]}"

and then in chroot.sh
# Importing Variables
args=("$@")
formfactor=${args[0]}
threadsminusone=${args[1]}
gpu=${args[2]}
boot=${args[3]}
disk=${args[4]}
username=${args[5]}
userpassword=${args[6]}
timezone=${args[7]}
swap=${args[8]}
intel_vaapi_driver=${args[9]}
res_x=${args[10]}
res_y_half=${args[11]}

still not they best way, kinda messy and buggy.

THANKS FOR HELP!

This entry was edited (3 hours ago)
in reply to DIY KARMA KIT

It would be more secure if the credentials are in an in memory SQLite Database but that would require you to use something other than the shell. You would need to do a hardware key or have the user do a bootstrap password or have an API that uses a public key to authenticate the remote process passing the credentials

don't like this

Introducing Operese(demo)


A Windows-to-Linux “translation” tool for the 200M+ Windows 10 computers not eligible to upgrade to Windows 11, Operese transfers files, settings, and programs from Windows to a brand-new Kubuntu installation. It's still very much a work in progress, but in my biased opinion, it already doesn't look too shabby!