Are you typing the commands all in one line? It's conceivable you are surpassing the maximum canonical length for the tty in which case the command is truncated. That can lead to some unexpected results. Remember, you can hit enter after any "|", "||" or "&&" and the command will continue on the next line (and the canonical limit is reset) or you can continue lines with a "\".

Dan Mercer
___________
Opinions expressed herein are my own and may not represent those of my employer.

Any particular reason you're using ksh88? Have you tried a different shell, like ksh93 or bash or something similar? Could be a bug in ksh88. Could be a bad keyboard tacking on an & at the end of the command line...

Any particular reason you're using ksh88? Have you tried a different shell, like ksh93 or bash or something similar? Could be a bug in ksh88. Could be a bad keyboard tacking on an & at the end of the command line...

I'm using ksh88 because that is what they have on that particular computer. They don't have ksh93 or even bash. I have no control over what they use. If I did, I would want to use zsh! I think one of the reasons why they stick with ksh88 is because it is the only shell that allows exported aliases. It's too bad the other shells don't have that capability; it's a very useful feature.

I don't think it's the keyboard. When I do put an & at the end, the command terminates normally and the shell doesn't freeze. I'll bet it is a bug in ksh88, but I seem to be the only one who sees it.

Lyle Goldman

In article <3AD66F5F.6040603@erols.com>, Lyle Goldman
<gizmo-p@erols.com> writes:
> Mathew Kirsch wrote:
> >
>
>> Lyle Goldman wrote:
>>
>> > Yes, I usually do type the commands all on one line. However, this
>> > also happens with very short commands (although some are actually
>> > aliases for longer commands, but that has nothing to do with the
>> > terminal), so I don't think that's the problem. The commands are
>> > executing correctly; the shell just puts it in its job list. When
>> > I do a "jobs -l" command, the command is listed exactly as I typed
>> > it, and I can't get rid of it.
>>
>>
>> Any particular reason you're using ksh88? Have you tried a different
>> shell, like ksh93 or bash or something similar? Could be a bug in
>> ksh88. Could be a bad keyboard tacking on an & at the end of the
>> command line...
>
> I'm using ksh88 because that is what they have on that particular
> computer. They don't have ksh93 or even bash. I have no control
> over what they use. If I did, I would want to use zsh! I think one
> of the reasons why they stick with ksh88 is because it is the only
> shell that allows exported aliases. It's too bad the other shells
> don't have that capability; it's a very useful feature.

Only in scripts that do not begin with a hashbang, i.e. "#!/bin/ksh".

>
> I don't think it's the keyboard. When I do put an & at the end,
> the command terminates normally and the shell doesn't freeze. I'll
> bet it is a bug in ksh88, but I seem to be the only one who sees
> it.
>
> - Lyle Goldman
>

Are the commands that you see this behavior programs or shell scripts. If
shell scripts, do you have ENV set? It's probable the problem lies in
your ENV file.

--
Dan Mercer damercer@mmm.com

Opinions expressed herein are my own and may not represent those of
my employer.

When ksh runs a piped list interactively, it associates a job with each pipeline (if the monitor option of the set command is on). So that you get a "stuck job" might well be the expected behavior.

Another possibility re: your problem of "stuck jobs": Do the scripts/commands you try have some task in common when they blow up?
e.g. One legitimate reason for a job to quit is if its in the background and attempts to write output with "stty tostop" in effect...

...both of these ideas gleaned from ksh docs on Solaris 2.7

Good luck,
Brett.