Search Results

Yes, by vanilla sh I didn't necessarily mean POSIX. There are some old shells out there.

I doubt -- and hope -- their ksh isn't 100% compatible, since Solaris' usual idea of backwards compatibility is denying you all future features in the standard /bin/whatever, making you use...

That's kind of a 'warning: water is wet' kind of thing. #! lets you pick awk, perl, or csh, let alone a merely non-POSIX shell.

I get tired of hearing ksh being called "portable" when it's available almost nowhere I go unless I install it myself, and people keep banging their heads on ancient versions which have almost none...

You're not bothering me, I don't have to talk to you if I don't want to. Honestly, sometimes I like a good argument.

Still think you're missing something but you'll figure it out.

Maybe it's "conceptionally" the same but it's not actually the same. That's kind of more important. But code written for the Bourne shell ought to and does work in any of them -- but might not work...

That's already valid syntax that already does something completely different.

FD=0
cat <&$FD

Shoehorning your solution in there will break existing code. Pick something else. ...aside from...

Sorry for going off-topic. "Features of a new shell" might do as a topic if you split it.

Noted. I don't agree. We already use $. This'd change the meaning of plenty of existing code where $f would be a file name. Unless you decide to do both, in which case this is a line of code that...

Which is the model we have already. Your point? A few good reasons:

1) Right now there's no "special" files in a shell, you can do as you please even with stdin/stdout/stderr. Adding new...

The only time the shell knows it's done with a file descriptor is when it quits! It's not psychic... If it doesn't give you a minimal model of the kernel's I/O, I don't think you could call it a...

The shell is a more direct interface to the environment and the kernel than a lot of people realize. File numbers in shell are the file descriptor numbers the kernel has actually assigned to this...

I guess I'm not familiar enough with vi-mode editing to understand why the semicolons matter. Sorry.

Yes, it is a nitpick, because you're not pointing out a broken or missing feature: You're just complaining that it's not ksh. I do multi-line editing quite frequently. BASH substitutes semicolons...

That's just nitpicking, then. They're both equally ugly, and bash's "modification" doesn't change it in any way that actually matters.

Sorry, crosspost. I tried vi mode too, which mashed it all on one big line. I'm building a newer ksh(2009 release, as opposed to the 2007 I had before) and we'll see if that's got the multi line...

Not here they don't. $ ksh --version
version sh (AT&T Research) 1993-12-28 s+
$ ksh
$ set -o emacs
$ for a in 1 2 3
> do
> echo $a
> done
1
2
3
$ for a in 1 2 3
> The last line...

Very true. Er, which ksh are you using? On my system, AT&T ksh93 "preserves" multi-line command history by only recalling the first line! :) Interesting.

Any that run it as #!/bin/sh, that's who: ...When invoked as sh, bash
enters posix mode after the startup files are read. ...which I almost always do. Only when...

Oh, that is far too easy.
http://burningsmell.org/images/cshell.jpg
Sorry, I'll stop now.

I'd love perl if it wasn't so resource intensive. I wrote an awesome Perl/MySQL script for a web inventory, then watched them install and use it on their server -- which turned out to be a P133 with...

bash. It lets you group things in useful ways some don't realize. You can redirect the output of not just individual programs, but entire loops.


for ((N=0; N<10; N++))
do
echo "This is...