3

I don't understand the problem about which the standard shell in Debian (dash) complains:

test@debian:~$ sh
$ man ls

ctrl+Z

[1] + Stopped                    man ls
$ jobs
[1] + Stopped                    man ls
$ fg %man
sh: 3: fg: %man: ambiguous

Shouldn't fg %string simply bring the job whose command begins with string to the foreground? Why is %man ambiguous?

  • 1
    without referring to the source, I suspect dash is expecting numeric job IDs, and so is failing in some way to translate "man" to a number. – Jeff Schaller Jun 1 '16 at 18:56
  • Also, aside from this bug you've found....dash is a minimal posix sh, intended mainly for scripting rather than interactive use (it's fast because it doesn't carry around all the bloat/baggage that bash etc do). IMO, it's best to use something else (bash, ksh, or zsh, for example) as your interactive command-line shell. BTW, bash is still an Essential: yes package (at least on amd64 and i386, if not other arches), so will be installed on all Debian systems. – cas Jun 2 '16 at 5:41
  • @cas: I normally use bash. For learning purposes I wanted to have a shell installed that comes close to the FreeBSD sh which is very minimal. What would be another option besides dash? – wolf-revo-cats Jun 7 '16 at 2:36
  • even on freebsd you don't have to use their minimal sh as your interactive shell. install and use bash, but still write your scripts for portability using #!/bin/sh and only use shell features supported by sh. – cas Jun 7 '16 at 2:39
  • @cas: Yes, of course, but I never claimed that one cannot use bash on FreeBSD. The FreeBSD sh was just an example for the kind of shell which I want. – wolf-revo-cats Jun 7 '16 at 3:28
5

This looks like a bug; the loop which handles strings in this context doesn't have a valid exit condition:

        while (1) {
                if (!jp)
                        goto err;
                if (match(jp->ps[0].cmd, p)) {
                        if (found)
                                goto err;
                        found = jp;
                        err_msg = "%s: ambiguous";
                }
                jp = jp->prev_job;
        }

If a job matches the string, found is set, and err_msg is pre-loaded; then it goes round the loop again, after setting jp to the previous job. When it reaches the end, the first condition matches, so control goes to err, which prints the error:

err:
        sh_error(err_msg, name);

I guess there should be a goto gotit somewhere...

The following patch fixes this (I've sent it to the upstream maintainer):

diff --git a/src/jobs.c b/src/jobs.c
index c2c2332..37f3b41 100644
--- a/src/jobs.c
+++ b/src/jobs.c
@@ -715,8 +715,14 @@ check:

        found = 0;
        while (1) {
-               if (!jp)
-                       goto err;
+               if (!jp) {
+                       if (found) {
+                               jp = found;
+                               goto gotit;
+                       } else {
+                               goto err;
+                       }
+               }
                if (match(jp->ps[0].cmd, p)) {
                        if (found)
                                goto err;
1

Apparently the dash version of fg have some bug or limitation to bring up the process when using a string instead of the job number.

What you can do is to use the number instead of the process name, like that:

fg %1 

Im very sorry to say that!

In bash it works fine with the name, remember that fg is a shell built-in for the two shells, so fg of bash is not exactly the same command in dash and can have different bugs or limitation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.