Your favorite shell in FreeBSD

My (limited) understanding: If a shell can pass all of the Posix compliance tests, it is Posix conformant. None of those tests use non-Posix features, so a shell that has additional features could pass. Let me give a really simple example: A normal shell has commands such as set, if, for. A new shell might have a command called "foo", which when executed would cause purple elephants to fly around your screen. Since none of the tests will execute foo, the new shell would pass the test.

The other bit of advice: The way to write scripts that use ONLY Posix features is not to write them on some shell that is rumored to be Posix conformant, and then if the scripts work, they must be Posixly correct. Instead, as you write the scripts, have a book or printout of the Posix standard next to you, and use it as a reference. O'Reilly used to have really good books about the Posix C interfaces (Posix.1 and Posix.4); I suspect there are good books about the Posix shell too.
 
ralphbsz mostly agree.

The fact that a shell can do more than specified by POSIX doesn't automatically make it non-compliant. And additional commands are trivially safe, for most commands it's unspecified whether they are builtins or external utilities, and additional utilities in your PATH, where the shell would find and execute them, are always allowed, for obvious reasons.

Extending the syntax of commands/utilities that *are* specified by POSIX isn't that trivial any more. The example above was about test, I would conclude it is safe because the POSIX specification for test just states something like "anything else has undefined results", IIRC. But say it would require something like a diagnostic about "invalid" syntax, and you'd immediately have a compliance issue with your extension.

As for how to write portable scripts, I also agree: Refer to the standard! I think the documents you'll find published online, like e.g. Shell Command Language (and all the descriptions of shell utilities also found there), should suffice. Still, it's sometimes easy to overlook something, therefore testing in actual shells is also a part, ideally a few different implementations. That's where I found pbosh(1) from shells/bosh pretty helpful, it claims to do "POSIX and nothing else", and it indeed exposed an issue for me before.
 
I find writing portable shell scripts as an exercise in futility. Try writing a portable shell script for finding setuid binaries and you will find that GNU find doesn't support the '+' sign in `-perm +06000` using '/' instead.

So I use Bashisms most of the time because I need true lists and associative arrays.

We have other scripting languages for writing scripts that are intended to be portable.
 
Hi ralphbsz, zirias@,

thank you for the replies.

My question re the compliance was really about how it affects writing scripts. Your advises essentially solve my inquiry, regardless of the strict definition of POSIX compliant shell.

Kindest regards,

M
 
SirDice said:
One of the reasons why I liked csh/tcsh was the way the history worked. It does a backwards search by default. Just type the first couple of characters of the command and press the <up> key, I am so used to that now.
Click to expand...
Same reason why I was using /bin/tcsh and the % prompt character feeling cool than ordinary $. I like having a colored shell prompt but that doesn't look good when I do capture terminal output with script(1). I think I am seeing color codes in the typescript too, to workaround this, for now i have switched to /bin/sh and configured all my /bin/tcsh settings in both ~/.shrc and ~/.profile. I wonder if i can use tput(1) to color my shell prompt without messing the typescript.
 
When I started using FreeBSD, I tried the different shells offered at install time and accidentally found csh's ability to retrieve commands from history (using up/down arrow keys after a first few characters are typed). I have been using csh since then, for user. For root, I leave it at the default.
 
I tried jumping on the fish bandwagon but I came back to bash yesterday. I need to use bash for work so there's no point learning two different and somewhat incompatible scripting languages just for the sake of it and honestly I don't like the direction that fish developers are pointing to.

I also took the opportunity to convert all my fish/bash scripts to pure sh so on my FreeBSD machine I'm basically using bash only for interactive purposes.
 
I'm using zsh for interactive shell including root, and /bin/sh for scripting shell (using shebang line).
But my (and root's, too) login shell is tcsh.

This can be automated with
Code: 
if ( -X zsh && -f ~/.Use_zsh ) exec zsh
in ~/.tcshrc.mine for each user and creating ~/.Use_zsh (can be a blank file).
By deleting ~/.Use_zsh (or absense of zsh whereever in PATH environment variable), tcsh is used on next login.
 
I've been using bash for both users and root (I've never seen an issue with that). I prefer having a single known entity regardless of the system I'm logging into.
 
Bless you "default" guys. The other community members made me feel like a slightly slothful slacker for using Bourne and C shell.
 
SirDice said:
One of the reasons why I liked csh/tcsh was the way the history worked. It does a backwards search by default. Just type the first couple of characters of the command and press the <up> key, I am so used to that now. Bash can be configured similarly but doesn't feel the same and is certainly not configured by default that way. The original /bin/sh of FreeBSD had very little command history, certainly no persistent history. So tcsh was just a better interactive shell to use that was always available.
Click to expand...
After I upgrade to FreeBSD 14.2 I changed from /bin/csh to /bin/sh. Is any way to make /bin/sh work with history and <up> key like csh?
 
You must log in or register to reply here.
Back
Top