I still use an HP-200LX (actually, I have two that work, and another for parts). This is basically a PC-XT in a hardshell calculator-sized case. It runs MS-DOS, and uses a PCMCIA card for "disk space". The screen is basically B&W CGA. Runs "forever" on two AA cells - and can recharge them "intelligently" right in the unit!
The IR link is Pre-IRDA, so there are problems in communicating with other machines (you need to download an IRDA driver), and a few other quirks. However, it is a wonderful machine with an almost-fanatical following.
Sorry...I have "set -e" in my $ENV processor subshell.ksh) when running a non-interactive shell, so I don't normally have to type it by hand. A better example would be:
set -e
trap "echo error" ERR
true | false | echo "shouldn't be here"
I'm not certain what you're asking...your
perl doesn't work on my interpreter (bad
loop variable). It looks as if you're trying
to display the environment in a seperate
(child) process. If so, in KSH you'd use
something like:
(
env
#
# other stuff in your child-process...
) &
Child_PID=$!
#
# other stuff in your parent-process...
The above is a multiline command (not just one that affects multiple lines). The terminating backslash on all but the last line is, of course, required. The vi implementations I've used don't support this approach...
Wrong viewpoint:
g/foo/-1 s/bar/barre/\
+2s/Alpha/Beta
The above is a multiline command (not just one that affects multiple lines). The terminating backslash on all but the last line is, of course, required. The vi implementations I've used don't support this approach...
I have a suite of scripts and functions that I recently implemented to handle MS-SQL Server/7 from KSH. I currently do quite a bit of automated database processing from KSH.
I've just finished a (less satisfactory) package for dealing with Oracle, too.
I'm still partial to 'ed'. Quick, easy (since I learned all it's commands before vi was invented), and lightweight. Also, despite claims to the contrary, the command-line mode in vi *cannot* do everything that ed can - multiline commands, for example.
I don't know about "world's best GUI"...and KSH is inherently CLI-oriented (and thus, not much related to whatever GUI you want to use). However, Mortice Kern Systems has been selling various incarnations of its "MKS Toolkit" since the mid-80's. I've been using their Korn-Shell as my preferred CLI under MS-DOS for over 15 years. Their version for Windows/NT is pretty good, too.
A minor gripe about the korn-shell is that variables set within while or for loops tend to fall "out of scope" outside the loop. This is a bit of a hassel when trying to generate a stream-parser that sets variables based on tags (rather than position-within-stream).
It might be worthwhile to consider a "set" flag that allows controlling this behavior.
My only significant gripe with the current Korn-Shell specs is that errors that occur within a pipeline (except in the last element thereof) don't trigger traps. For example:
will not trigger the "echo error" action, but will instead try to read from the console. This is a real problem when trying to build "industrial strength" scripts, because error-trapping is a critical part of that. Sure, you could just say "don't use pipes"...but that cripples one of the main advantageous features of the shell!
My main reason for preferring the Korn-Shell to Perl is familiarity. I use ksh as my main command-line-interface (CLI), so it is almost second nature to me.
I am probably as close to a Korn-Shell "guru" as anyone this side of Mr. Korn, so I'm definitely prejudiced, here. However, I generally find it easier to "hand off" a shell-script to moderately technical users, than a Perl script. It's just easier for them to read and understand, because they use many of the commands every day.
I, for one, have been using the Mortice Kern System's kornshell and UNIX-style utilities (MKS Toolkit) on MS-DOS, and now Windows/NT, since the mid-80's. The Korn-Shell is definitely my CLI of choice, and one of the best scripting languages I've encountered.
Interestingly enough, when Microsoft still sold Xenix (as part of its attempt to fragment the UNIX community, I think), the best shell for it was also produced by MKS. Xenix didn't ship with a Korn-Shell, just a Bourne-Shell and C-Shell.
I started out with the Bourne Shell under UNIX v6, and loved it. The Korn shell is, IMHO, just a (significantly) improved Bourne shell.
Slashdot Mirror
I still use an HP-200LX (actually, I have two
that work, and another for parts). This is basically a PC-XT in a hardshell calculator-sized
case. It runs MS-DOS, and uses a PCMCIA card for
"disk space". The screen is basically B&W CGA. Runs "forever" on two AA cells - and can recharge them "intelligently" right in the unit!
The IR link is Pre-IRDA, so there are problems in communicating with other machines (you need to download an IRDA driver), and a few other quirks. However, it is a wonderful machine with an almost-fanatical following.
Sorry...I have "set -e" in my $ENV processor subshell.ksh) when running a non-interactive shell, so I don't normally have to type it by hand. A better example would be:
set -e
trap "echo error" ERR
true | false | echo "shouldn't be here"
I'm not certain what you're asking...your
perl doesn't work on my interpreter (bad
loop variable). It looks as if you're trying
to display the environment in a seperate
(child) process. If so, in KSH you'd use
something like:
(
env
#
# other stuff in your child-process...
) &
Child_PID=$!
#
# other stuff in your parent-process...
Sorry - the HTML formatter ate the lines...
Wrong viewpoint:
g/foo/-1 s/bar/barre/\
+2s/Alpha/Beta/
The above is a multiline command (not just one that affects multiple lines). The terminating backslash on all but the last line is, of course, required. The vi implementations I've used don't support this approach...
Wrong viewpoint: g/foo/-1 s/bar/barre/\ +2s/Alpha/Beta The above is a multiline command (not just one that affects multiple lines). The terminating backslash on all but the last line is, of course, required. The vi implementations I've used don't support this approach...
Actually...
I have a suite of scripts and functions that I recently implemented to handle MS-SQL Server/7 from KSH. I currently do quite a bit of automated database processing from KSH.
I've just finished a (less satisfactory) package for dealing with Oracle, too.
I'm still partial to 'ed'. Quick, easy (since I learned all it's commands before vi was invented), and lightweight. Also, despite claims to the contrary, the command-line mode in vi *cannot* do everything that ed can - multiline commands, for example.
I don't know about "world's best GUI"...and KSH is inherently CLI-oriented (and thus, not much related to whatever GUI you want to use). However, Mortice Kern Systems has been selling various incarnations of its "MKS Toolkit" since the mid-80's. I've been using their Korn-Shell as my preferred CLI under MS-DOS for over 15 years. Their version for Windows/NT is pretty good, too.
A minor gripe about the korn-shell is that variables set within while or for loops tend to fall "out of scope" outside the loop. This is a bit of a hassel when trying to generate a stream-parser that sets variables based on tags (rather than position-within-stream).
It might be worthwhile to consider a "set" flag that allows controlling this behavior.
My only significant gripe with the current Korn-Shell specs is that errors that occur within a pipeline (except in the last element thereof) don't trigger traps. For example:
trap "echo error" ERR
echo "hello" | false | cat -
will not trigger the "echo error" action, but will instead try to read from the console. This is a real problem when trying to build "industrial strength" scripts, because error-trapping is a critical part of that. Sure, you could just say "don't use pipes"...but that cripples one of the main advantageous features of the shell!
My main reason for preferring the Korn-Shell to Perl is familiarity. I use ksh as my main command-line-interface (CLI), so it is almost second nature to me. I am probably as close to a Korn-Shell "guru" as anyone this side of Mr. Korn, so I'm definitely prejudiced, here. However, I generally find it easier to "hand off" a shell-script to moderately technical users, than a Perl script. It's just easier for them to read and understand, because they use many of the commands every day.
I, for one, have been using the Mortice Kern System's kornshell and UNIX-style utilities (MKS Toolkit) on MS-DOS, and now Windows/NT, since the mid-80's. The Korn-Shell is definitely my CLI of choice, and one of the best scripting languages I've encountered. Interestingly enough, when Microsoft still sold Xenix (as part of its attempt to fragment the UNIX community, I think), the best shell for it was also produced by MKS. Xenix didn't ship with a Korn-Shell, just a Bourne-Shell and C-Shell. I started out with the Bourne Shell under UNIX v6, and loved it. The Korn shell is, IMHO, just a (significantly) improved Bourne shell.