I've recently been playing with the legacy Bourne Shell from the GitHub repo [heirloom-sh](https://github.com/grml/heirloom-sh) . It's installed at /usr/local/bin/sh with no symlinks. One script is invoking it via #!/bin/env sh. *I'm running Manjaro with system and packages fully up to date as of this post (vscodium-bin 1.99.02289-1, Manjaro 6.12.20-2-MANJARO). I posted concisely on their forum , but this issue goes way beyond even Arch stacks, affecting all Linux development.* ## Background Most of our Linux scripts are written for BASH (/bin/bash) and cannot work for Bourne Shell (implied by /bin/sh, but not reliable ). But, many coders still put #!/bin/sh for the shebang (#!/...) anyway, then code as if for the BASH #!/bin/bash. For most systems, /bin/sh is a link to /bin/bash, letting everything for BASH work in a mis-labaled Bourne Shell script. This has resulted in some sloppy programming practices and breaks the rule from Chemistry class: "Never make labels lie." For Debian, /bin/sh is a link to /bin/dash (Debian Almquist shell, POSIX minimal), carrying many Bourne Shell limits. So, Debian/Ubuntu devs might not run into the same problems of BASH scripts still working with #!/bin/sh. Thus, this may mostly be a non-Debian dev issue. ...mostly. # Examples of resulting errors ## Eg. VSCodium I first noticed this as a non-system issue with the AUR packages vscodium and vscodium-bin (I'm using vscodium-bin). /opt/vscodium-bin/bin/codium (where VSCodium resides) had this as line 1:

#!/usr/bin/env sh

...which would not start from the GUI, and then from the CLI threw this error:

/opt/vscodium-bin/bin/codium: syntax error at line 20: `YN=$' unexpected

I had two solutions: 1. Comment and changed the shebang line to this:

#!/usr/bin/bash

...then it worked. 2. Remove /usr/local/bin/sh (my legacy sandbox authentic Bourne shell, see above)... I reversed line 1 that so that /opt/vscodium-bin/bin/codium once again had this as line 1:

#!/usr/bin/env sh

...as it does OOB, then I removed /usr/local/bin/sh. Then it also worked. ***Technically, #!/usr/bin/env sh might not be POSIX compliant if it invokes BASH-only code.*** So, that would be an example of this coding issue happening with an actual project, VSCodium specifically. ## Eg. Manjaro Boot I mentioned this in my Manjaro Forum post , but basically having /bin/sh as an actual, true legacy /bin/sh Bourne shell broke my boot sequence. That tells me that many of my distro's most-current startup boot processes and scripts are actually using BASH code with a Bourne shell shebang. On Arch, not only Manjaro, /bin/sh is a symlink to bash, presuming the same PWD; it isn't even an absolute link, but a relative link! Arch:

# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 May  5  2025 /bin/sh -> bash

The boot issue on Manjaro is unlikely from developers changing an Arch file with #!/bin/bash into #!/bin/sh. Many of our implied, forgotten, invoked system startup scripts are probably inherited from the runlevel era. This is a legacy issue, after all. I'm scratching my head on how in the Linux-world that was even able to come from mainstream distro-level developers. # Summary We still have Bourne Shell artifacts in the form of #!/bin/sh floating around out there, even in our most current Linux distros, still being created in the developer world. If ever /bin/sh actually is /bin/sh, many Linux systems won't boot! This makes big problems for any portability. In fact, this might even be a security issue: Make /bin/sh actually become /bin/sh and every Linux server can't reboot. ___ These surrounding questions come to mind. How far does it reach into our Unix/Linux world to have /bin/sh --> bash? Is it POSIX compliant to use #!/usr/bin/env sh, then invoke code that only works with #!/bin/bash *and does not work* with #!/bin/sh? If POSIX compliant, why and would it break any other coding guidelines? Has the Linux world addressed BOLO to make sure we aren't using Bourne Shell (#!/bin/sh) in our scripts unless we are writing for the legacy Bourne Shell last updated for capabilities in 1989? Should we all be looking through our code and removing any #!/bin/sh meant to run on modern systems that probably have a link to /bin/bash anyway? Even consider removing the /bin/sh link to /bin/bash altogether? In light of not relying on sh at /bin/sh , if we thus should not use #!/bin/sh in referencing BASH code (that is if), then *theoretically* should Debian scripts use #!/bin/dash instead of #!/bin/sh? Or, is Debian's dash close enough to sh that it fits current POSIX expectations? How much has this already been discussed and what are the current resolutions across the Linux world? Is there another reason we need "labels to lie" and that using #!/bin/sh-labeled code (that can't run on actual 1989 Bourne Shell's /bin/sh) is a good idea? Does this issue only affect Linux or also Unix? Do Apple scripts use #!/bin/sh with symlink?

I want to try out Bourne shell on FreeBSD so I am starting to set it up for my use. In .shrc, I set my prompt, enabled vi mode, set some aliases, and exported some variables. However, I see that .profile also, by default, exports some variables. It is my understanding that Bourne shell will source .profile on each startup. If so, what is the (historical) reason for having both .shrc and .profile?

I wrote a small script today which contained grep -q ^local0 /etc/syslog.conf During review, a coworker suggested that ^local0 be quoted because ^ means "pipe" in the Bourne shell. Surprised by this claim, I tried to track down any reference that mentioned this. Nothing I found on the internet suggested this was a problem. However, it turns out that the implementation of bsh (which claims to be the Bourne shell) on AIX 7 actually has this behaviour: > bsh $ ls ^ wc 23 23 183 $ ls | wc 23 23 183 None of the other "Bourne shell" implementations I tried behave this way (that is, ^ is not considered a shell metacharacter at all). I tried sh on CentOS (which is really bash), and sh on FreeBSD (which is not bash). I don't have many other systems to try. Is this behaviour expected? Which shells consider ^ to be a pipe metacharacter?

I am reading the [source code of the Maven wrapper written for the Bourne shell](https://github.com/apache/maven-wrapper/blob/102d7b50cd756b0ac922ef07378c1fe3c9686473/maven-wrapper-distribution/src/resources/mvnw#L103) . I came across these lines:

if [ -z "$JAVA_HOME" ]; then
    javaExecutable="$(which javac)"
    if [ -n "$javaExecutable" ] && ! [ "$(expr "$javaExecutable" : '\([^ ]*\)')" = "no" ]; then
# snip

expr when used with arg1 and arg2 and a : matches arg1 against the regex arg2. Normally, the result would be the amount of matching characters, e.g.:

$ expr foobar : foo
3

However, when using capturing parentheses (\( and \)), it returns the content of the first capturing parentheses:

$ expr foobar : '\(foo\)'
foo

So far, so good. If I evaluate the expression from the source quoted above on my machine, I get:

$ javaExecutable=$(which javac)
$ expr "$javaExecutable" : '\([^ ]*\)'
/usr/bin/javac

For a non-existing executable:

$ nonExistingExecutable=$(which sjdkfjkdsjfs)
$ expr "$nonExistingExecutable" : '\([^ ]*\)'

Which means that for a non-existing executable the output is a empty string with newline. What's puzzling me in the source is how the output of which javac (arg1 to expr) ever returns the string no? Is there some version of which which, instead of returning nothing, returns no when no executable can be found? If not, this statement always evaluates to true and that would be weird.

I have a variable that contains a list of strings, one per line, to be looped over in a for...in...do...done command. I move regularly between bourne shell and zsh. As far as I can understand it, zsh doesnt by default split words out of a a string at newline or whitespace; bourne shell does. So commands like for list_item in $list; do... fail in zsh whereas they'd work in bourne shell, or with literal text rather than variable. Ive tried playing with IFS= in the command, and quoting the variable, but can't seem to make progress. Is there a single syntax for a loop over the words/lines in the string, that will work unmodified in both shells, for ease? if not, what's best practice?

I understand the concepts of terminal, console, shell and their differences. I know a shell today is an interpreter that communicates with the OS kernel to perform some actions and does it through terminal applications. But in the old days when computers didn't had GUI, all the interaction a user had with a computer was through the shell? I've read that the Bourne Shell (sh) was introduced in Unix version 7, was that like, you turn on the computer and from the moment you start typing you are communicating with sh? or you had to enter the sh program through a command and then that shell starts? And kind of the same with windows or Mac, is that MS-DOS functionality what we have today in cmd? Thanks in advance and if someone can leave a documentation where this evolution is explained I'll be very grateful.

bash v3.2 (though I think holds for newer versions too): In section 3.7.4 Environment, the docs say: > On invocation, the shell scans its own environment and creates a parameter for each name found, automatically marking it for export to child processes. And later in Appendix B Major Differences From The Bourne Shell, the docs say: > Variables present in the shell’s initial environment are automatically exported to child processes. The Bourne shell does not normally do this unless the variables are explicitly marked using the export command. I don't understand what this means. In the following, cmd1.sh comprises #!/bin/bash echo yes $ben from cmd1 ./cmd2.sh And cmd2.sh comprises #!/bin/bash echo yes $ben from cmd2 I first understood the docs to mean that *all* assigned variables will be exported (ie there was no need to export variables), ie when running ben=you; ./cmd1.sh I expected this to print yes you from cmd1 yes you from cmd2 But instead it prints yes from cmd1 yes from cmd2 So variable ben doesn't appear to be automatically exported. Then I thought the docs might instead mean that all *environment* variables will be exported, ie when running ben=you; export ben; ./cmd1.sh Because cmd1 receives an environment variable of ben, then ben will be automatically exported such that it will be visible in cmd2. Ie I expected this to print the following (and indeed the following is printed): yes you from cmd1 yes you from cmd2 However, to test whether this is different from Bourne shell (as the docs claimed) I ran the exact same commands, but changing the shebang to point to /bin/sh instead of /bin/bash, and I obtained the exact same result. Ie I did not see any difference. In Bourne shell, I was expecting to see an output of something like yes you from cmd1 yes from cmd2 Can anyone help me to understand what the docs are referring to when they talk of "automatically" marking parameters for export, and how this is different to Bourne shell? Nb I did spot this question regarding a specific difference between export behaviour in bash and bourne, but that doesn't seem to be relevant.

I am on a closed network (i.e. no connectivity to the internet). I have a bourne shell script that asks for the user to enter a regular expression for use with grep -P. Generally speaking, I like to do some form of input validation. Is there a way to test a string variable to see if it is a (valid) regex? (Copying things from the internet onto my system can be done, but it takes forever and is a PITA -- thus I am looking for way to do it natively.)

Arising from [this](https://unix.stackexchange.com/questions/685602/count-bytes-of-filename/685603?noredirect=1#comment1295723_685603) discussion: When I have (zsh 5.8, bash 5.1.0)

var="ASCII"
echo "${var} has the length ${#var}, and is $(printf "%s" "$var"| wc -c) bytes long"

the answer is simple: these are 5 characters, occupying five bytes. Now, var=Müller yields

Müller has the length 6, and is 7 bytes long

Which suggests the ${#} operator counts codepoints, not bytes. This is a bit unclear [in POSIX](https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/utilities/V3_chap02.html#tag_18_06_02) , where they say it counts "characters". This would be clearer if characters in POSIX C weren't octets, normally. Anyways: Nice! Kind of good, seeing that LANG==en_US.utf8. Now,

var='🧜🏿‍♀️'
echo "${var} has the length ${#var}, and is $(printf "%s" "$var"| wc -c) bytes long"

🧜🏿‍♀️ has the length 5, and is 17 bytes long

Soooo, we decompose "Mermaid of dark skin color" into the Unicode codepoint 1. Merperson 2. Dark skin tone 3. Zero-Width Joiner 4. Female 5. Print print the previous character as emoji Fine, so we're really counting Unicode codepoints!

var="e\xcc\x81"
echo "${var} has the length ${#var}, and is $(printf "%s" "$var"| wc -c) bytes long"

é has the length 9, and is 9 bytes long

(of course, my console font decided that the ´ combines with the following space, not the preceding e. The latter would be correct. But let's leave my rage about that for somewhen else.) Um, a slight "wat" is in order here.

> printf "e\xcc\x81"|wc -c
3
> printf "%s" "${var}" |wc -c
9
> echo -n ${var} |wc -c
3
> echo "${var} has the length ${#var}, and is $(printf "%s" "$var"| wc -c) bytes long"
é has the length 9, and is 9 bytes long
> printf "%s" "${var}" |xxd
00000000: 655c 7863 635c 7838 31                   e\xcc\x81

Here's where I give up. echo $var, echo ${var} and echo "${var}" all "correctly" emit three bytes. However, echo ${#var} tells me it's 9 charachters. Where is this documented/standardized, what's the rules for all this?

I know how to create an arithmetic for loop in bash. How can one do an equivalent loop in a POSIX shell script? As there are various ways of achieving the same goal, feel free to add your own answer and elaborate a little on how it works. An example of one such bash loop follows: #!/bin/bash for (( i=1; i != 10; i++ )) do echo "$i" done

What is extension & execution command for following file formats - Bourne Shell, Korn Shell, Bourne Again Shell, POXIS shell & TENEX/TOPS C Shell. Like normal bash file can be created with '.sh' extension & can easily be executed by command - 'shell filename.sh'.

So, there are many types of shells in Linux... > Different Types of Shells in Linux > > The Bourne Shell (sh) ...
> The GNU Bourne-Again Shell (bash) ...
> The C Shell (csh) ...
> The Korn Shell (ksh) ...
> The Z Shell (zsh) I have a project where I have to put together a script for the Bourne shell, starting with shebang **#!/bin/sh**. But whenever I use Google to learn about some detail, I always get tons of results for **bash**, which I suspect are ok to use with **sh**, but not always... So I want to tell Google, "No! Give just stuff for the original Bourne shell!". But people don't type the string "Bourne shell" into most of their web pages, so Google can't help me directly with that. Adding **"sh"** to my search query doesn't help much, it matches .sh file extensions, and it matches bash! Adding **"#!/bin/sh"** to my search query is _somewhat_ helpful - but I will see only results in scripts, when sometimes the simple anwsers are presented as terminal commands (which we can then adapt for use in scripts). I know there won't be any "silver bullet" perfect solution, but in a spirit of "tips and tricks", would any of you suggest clever ways to narrow down my results like I intend? Or is the only solution to use a handful of authoritative Bourne shell documentation sources? If so, which ones?

Help with deciphering commands [ $1 -ge 20 ] && telnetd -p 233 -l /bin/sh I know **/bin/sh** is a Bourne shell and telnetd is a telnet daemon but I'm not sure how they work together. I think someone tried to leave a back door open but I'm not sure what / how the other commands work together. Thanks

I set JAVA_HOME in .zshrc: export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre/ which is fine for interactive programs. But I have JVM programs running via cron, which uses Bourne shell. The bourne shell programs keep giving me this: groovy: JAVA_HOME is not defined correctly, can not execute: /usr/lib/jvm/default-java/bin/java What's the neatest way to solve this? I don't remember having to worry about this before. Currently I'm setting JAVA_HOME on every crontab entry which is burdensome and redundant.

I am writing an installation script that will be run as /bin/sh. There is a line prompting for a file: read -p "goat may try to change directory if cd fails to do so. Would you like to add this feature? [Y|n] " REPLY I would like to break this long line into many lines so that none of them exceed 80 characters. I'm talking about **the lines within the source code** of the script; *not* about the lines that are to be actually printed on the screen when the script is executed! What I've tried: - Frist approach: read -p "oat may try to change directory if cd fails to do so. " \ "Would you like to add this feature? [Y|n] " REPLY This doesn't work since it doesn't print Would you like to add this feature? [Y|n] . - Second approach: echo "oat may try to change directory if cd fails to do so. " \ "Would you like to add this feature? [Y|n] " read REPLY Doesn't work as well. It prints a newline after the prompt. Adding -n option to echo doesn't help: it just prints: -n goat oat may try to change directory if cd fails to do so. Would you like to add this feature? [Y|n] # empty line here - ###My current workaround is printf '%s %s ' \ "oat may try to change directory if cd fails to do so." \ "Would you like to add this feature? [Y|n] " read REPLY ###and I wonder if there is a better way. Remember that I am looking for a /bin/sh compatible solution.

#!/bin/sh echo -n "Enter the raspberry ip address you want to connect:" read Rasp_id sshpass -p "the@Donut" ssh -t -X -oStrictHostKeyChecking=no pi@$Rasp_id << E2 echo -e "Enter the case you want to echo\n 1.1 a \n 2.1 b" read option case "\$option" in 1) echo "a" ;; 2) echo "b" ;; esac E2 I'm writing a script that start a ssh session and then perform some modifications on remote machine, it will give syntax error as follow:

bash: line 3: syntax error near unexpected token `)'
bash: line 3: `        1)'

Sorry about the title it may not be clear. Here is the complete explanation of my doubt. I am writing the below shell script and expecting the mentioned output. #!/bin/bash python3 print("Hello World") exit() echo "The execution is completed" The output what i am expecting is, it should enter the python3 interpreter and execute the print and exit() commands and after executing the exit() command as the interpreter exits if we do it manually and then execute the echo command.But it is not working that way, after executing python3 it is entering the python3 interpreter but not executing the print and exit(). >>> It is entering the python3 correctly and then stops there till i manually exit the python interpreter. What changes should i make in order to get my expected output. 1. The follow up question: Is it possible to get the output Hello world or any other output that is generated in the python interpreter to bash environment and use it in the bash script. 2.And method which you specify to run the python commands will that work for other tools as well?

I'm generating a private key, this key is for demonstrable purposes only: $ openssl genrsa -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKCAQEAvB8fZFRS83Kztend5KO9cnWXaqLWot0qLDeLcS8ly718FUdm 3VcCY5j737zz4iwmFf3b20Q2XxlbYC/M13wTJzHBf2d1mRDlpZq7CgX/JSEUW/Hr uXiF6PI+ypkvskyoQcz04rlT8skd7tanXhXINnLwW7gCiNlxQQFkrpfO8Fkh+vYL ... Ewac3GAh9CiMikQEYNxpsuLLboS4NcaQWiGB+1imtPtbp8Gf89pJSVBDubgza2Bb rucNxP3HZtPd6G9CvkMJREYL7jHkXYa5DBzs9LB9mLB4b5H/6KN/fsfj -----END RSA PRIVATE KEY----- There is a newline \n at the end of each of these lines that needs removing, I want everything on a single line so I can set it to an env var. Note: I'm unable to store a multiline env var in .env as docker-compose doesn't support it. I've stripped out all the new lines with this: $(openssl genrsa | tr -d '\n') -----BEGIN RSA PRIVATE KEY-----MII...-----END RSA PRIVATE KEY----- I then manually insert two newlines \n which I'm looking to automate through a script (hence this post). If I don't do this the signing of the JWT fails. -----BEGIN RSA PRIVATE KEY-----\nMII...\n-----END RSA PRIVATE KEY----- I define it within a .env file JWT_PRIVATE_KEY=-----BEGIN RSA PRIVATE KEY-----\nMII...\n-----END RSA PRIVATE KEY----- With node and [dotenv](https://www.npmjs.com/package/dotenv) I access it like so: privateRsaKey = process.env.JWT_PRIVATE_KEY.replace(/\\n/gm, '\n'), Now privateRsaKey looks like this: -----BEGIN RSA PRIVATE KEY----- MII... -----END RSA PRIVATE KEY----- Now I actually use the private key to sign a [JWT](https://www.npmjs.com/package/jsonwebtoken) const signed = jwt.sign(payload, privateRsaKey, { algorithm: 'RS256', ... }); All of the above is working as expected when I bring up the Docker containers. **I need help in the scripting so I don't have to manually insert two \n** Thank you all for you help and patience it's much appreciated.

Is the relation between Bourne shell and Bash similar to that of C and C++(if so it would signify that both have their place as a shell)? Whenever I read something about shells it always says that Bourne shell is dead and obsolete, but why?

I'm trying to read two lines into two variables. In Bash I would use something like this: cat myfile line1 line2 EOF cat myfile | { read firstline echo $firstline # "line1" in bash and sh read secondline } echo $firstline # "line1" in bash, empty in sh echo $secondline In Bourne Shell however $firstline and $secondline are empty outside the command group. How can I do it in sh?