Results 1 to 7 of 7
  1. #1
    Lyle Goldman Guest

    Answered: Job Control in ksh

    Hello. I have been having a very annoying problem with ksh88 under Solaris. Every so often, when I enter a foreground command, the job control mechanism registers the command as a job. This happens especially with long pipelines. After the command is done, the job still exists, and can't be killed since the process doesn't exist any more. The worst part of this is that whenever there are any actual background jobs running and this happens, the shell freezes until all background jobs have exited. Has anyone even seen this happen before? What is causing this to happen, and how can I avoid it?

    By the way, here is the output from "uname -a":

    SunOS <host> 5.6 Generic_105181-15 sun4u sparc SUNW,Ultra-2

    Here is the ksh version information:

    Version M-11/16/88i

    Thank you for any help you can give me.
    Lyle Goldman

  2. Best Answer
    Posted by Lyle Goldman

    "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 other ideas?

    Lyle Goldman
    "


  3. #2
    Dan Mercer Guest
    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.

  4. #3
    Lyle Goldman Guest
    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 other ideas?

    Lyle Goldman

  5. #4
    Mathew Kirsch Guest
    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...

  6. #5
    Lyle Goldman Guest
    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

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

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

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

    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.

  8. #7
    Join Date
    Mar 2002
    Posts
    3
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •