Very Computer

I am trying to write a script to print only particular pages in a file
such as:  "print 3 4 11 14 test.ps" or "print 9 15 test.ps"

I can't seem to pick up the last parameter to use it in a script line
such as: "lpr2 $1 $N <--- the given filename to print from.

I've gleaned thru all the man and info pages, but I'm missing it somewhere.

TIA

--
|  The *s will continue     |          Bob Russell            |

|                                  |   http://www.veryComputer.com/~bobruss/  |
|         The Management.          |    San Rafael  Marin  CA  USA   |

From the UNIX-FAQ:

for LAST
do
        :
done

The for loop just assigns each of the parms in turn and does a NOP (":").
At the end the last arg is left in the for loop var.

Greetings, Michael
--

Case Western Reserve University         Lab phone: (216) 368 4034
"Who disturrrbs me at this time?"     << Zaphod Beeblebrox IV >>

|>> >I can't seem to pick up the last parameter to use it in a script line
|>> >such as: "lpr2 $1 $N <--- the given filename to print from.
|>>
|>> From the UNIX-FAQ:
|>> for LAST
|>> do
|>> :
|>> done
|>> The for loop just assigns each of the parms in turn and does a NOP (":").
|>> At the end the last arg is left in the for loop var.

|> I hate to, um, bash Bourne shell compatibility, but this does seem a
|> silly and indirect way to get at the last argument.  Two shells which
|> make this easier are rc and es, where the notation $*($#*) does the job.

|> In rc and es, $var(n) gives the nth element of $var, and $#var is the
|> number of elements in $var.  The shell variable $* holds the command
|> line arguments.  So $*($#*) follows directly.

|> Of course, if you are stuck with bash, this doesn't help.

Well, it does help, if you rewrite it a bit:

LAST="$(eval \${$#})"

--
Andreas Schwab                                      "And now for something

: I am trying to write a script to print only particular pages in a file
: such as:  "print 3 4 11 14 test.ps" or "print 9 15 test.ps"

: I can't seem to pick up the last parameter to use it in a script line
: such as: "lpr2 $1 $N <--- the given filename to print from.

: I've gleaned thru all the man and info pages, but I'm missing it somewhere.
don't know about bash specifics but since it is sh compatible you
can use:

        eval \$$#

kevin

The backslash defers the evaluation until `eval' gets hold of the line.
By the time eval runs, the `$#' has already been replaced with the number
of positional parameters, so eval sees something like

        lpr2 3 ${7}

assuming the first argument was `3' and there were 7 arguments to the
script.  You may want to double-quote the arguments if there's a chance
that any of the script arguments will contain characters special to the
shell.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer

   Thank you, everyone, for some useful and informative answers.
I'm pretty new at shell programming, and your responses have given me a
lot of avenues to peruse.

   Reading the man and info pages just don't give any examples, so I get
a bit confused with the wording and what exactly they refer to.

etc. still throws me, but perseverence furthers, to quote the I Ching.

SO, thanks again (I'll be Back, to quote....:)
Bob  
--
|  The *s will continue     |          Bob Russell            |

|                                  |   http://www.veryComputer.com/~bobruss/  |
|         The Management.          |    San Rafael  Marin  CA  USA   |

| LAST="$(eval \${$#})"

No, but you're close.  This will work in both bash and ksh (and in sh if
there are nine or fewer positional parameters):

        eval LAST=\${$#}

and of course, this does too, as previously suggested (and it also works
in sh):

        for LAST
        do :
        done

As Chet said, the workaround for bash (and ksh and POSIX shells) is to
use \${$#};  the ${} notation is not supported by older Bourne shells.

For example:

        bash$ set a b c d e f g h i j k
        bash$ eval echo \$$#
        a1
        bash$ eval echo \${$#}
        k
        bash$

But:

        sh$ set a b c d e f g h i j k
        sh$ eval echo \$$#
        a1
        sh$ eval echo \${$#}
        syntax error
        sh$

Paul

lastparameter="$_"

It's a special case.  You can't get at the second-last parameter this
way.

-zefram

--
Lloyd Zusman            01234567 <-- The world famous Indent-o-Meter.

   To get my PGP public key automatically mailed to you, please
   send me email with the following string as the subject or on a
   line by itself in the message (leave off the quotation marks):
                    "mail-request public-key"

   > > I hate to, um, bash Bourne shell compatibility, but this does seem a
   > > silly and indirect way to get at the last argument.  Two shells which
   > > make this easier are rc and es, where the notation $*($#*) does the job.
   >
   > I hate to, um, bash es and rc, but when will either of these shells
   > have job control?  Pretty good shells, otherwise.

   Probably never.  I can't speak about rc, but we have said that if
   someone can come up with a small number of primitives to add to es which
   will enable people to write job control as a user-level extension, we'd
   be happy to add them.

   On the other hand, job control is a hard thing to fit into es, where
   shell functions are extremely pervasive;  no shells that I know of
   handle ^Z (SIGSTOP) correctly if it comes in while a complex command or
   shell function is running.

   To give an idea of what I mean, let's take a simple example:

       touch foo; sleep 100; rm foo

   Run this in a job controlling shell.  Type Control-Z (or whatever
   character you use) during the sleep.  What happens?

   I've seen three answers, depending on which shell you use:

       (a) The control-z is ignored.
       (b) The sleep is stopped, and if it is continued (fore- or
           background), the ``rm foo'' is ignored.
       (c) The sleep is stopped and the rm happens right away.

   I've found no existing shell which does:

       (d) The sleep is stopped, and when it is continued, the rm
           is executed.

   To my thinking, (d) is the only correct answer.  I'm pretty sure
   the reason that most shells don't do it is that it's really hard to
   implement correctly, not that anyone thinks that (a), (b), or (c)
   is the right answer.  (My understanding of the state of the art may
   be outdated;  please correct me if I'm wrong and some shell does do
   the right thing.)

[snip]

I would say that (c) is the right behavior. If you want the whole
command to be treated as one job, you should write

        (touch foo; sleep 100; rm foo)

in order for the shell to put in in a subshell and run it. (At least
bash works this way, and if I'm not completely off, so does (t)csh)
If you don't do it this way, redirecting of stdin/stdout/stderr would
become difficult. For example, how would you interpretate a command
like this?

        echo foo; echo bar > myfile

Should myfile contain both foo and bar (the result of the whole
command), or should it only contain bar? (I know, this example
probably would win the `stupidest example award' if there was one,
but it's early in the morning and I haven't had my cup of morning
coffee yet, so....:)

/Stenis
--
**********************************************************************


* Newport Beach CA 92663        * Tel  : +1 714 675 4783 (home)      *
* USA                           *        +1 714 824 5086 (Office)    *
*                               * Fax  : +1 714 824 4056             *
**********************************************************************
There are very few personal problems that cannot be solved through a
suitable application of high explosives.
**********************************************************************

Quote:> > I hate to, um, bash Bourne shell compatibility, but this does seem a
> > silly and indirect way to get at the last argument.  Two shells which
> > make this easier are rc and es, where the notation $*($#*) does the job.

> I hate to, um, bash es and rc, but when will either of these shells
> have job control?  Pretty good shells, otherwise.

On the other hand, job control is a hard thing to fit into es, where
shell functions are extremely pervasive;  no shells that I know of
handle ^Z (SIGSTOP) correctly if it comes in while a complex command or
shell function is running.

To give an idea of what I mean, let's take a simple example:

    touch foo; sleep 100; rm foo

Run this in a job controlling shell.  Type Control-Z (or whatever
character you use) during the sleep.  What happens?

I've seen three answers, depending on which shell you use:

    (a) The control-z is ignored.
    (b) The sleep is stopped, and if it is continued (fore- or
        background), the ``rm foo'' is ignored.
    (c) The sleep is stopped and the rm happens right away.

I've found no existing shell which does:

    (d) The sleep is stopped, and when it is continued, the rm
        is executed.

To my thinking, (d) is the only correct answer.  I'm pretty sure
the reason that most shells don't do it is that it's really hard to
implement correctly, not that anyone thinks that (a), (b), or (c)
is the right answer.  (My understanding of the state of the art may
be outdated;  please correct me if I'm wrong and some shell does do
the right thing.)

The problem with job control for es is that everything just looks
like an es command.  There is no separation *at the language level*
between the internal things and the external ones.  The read-eval-print
loop is written in es itself, so how do you distinguish it from
a shell function?  If you don't implement job control in es as (d),
it just won't work at all, because the whole shell looks like one
big, convoluted shell command.

For more information on es, see

        http://www.webcom.com/~haahr/es/es-usenix-winter93.html

Paul

Quote:> If you want the whole
> command to be treated as one job, you should write

>    (touch foo; sleep 100; rm foo)

> in order for the shell to put in in a subshell and run it.

The problem is, if you're running a function, which is running
a function, which is running a function (etc), and you control-Z
them, you'd expect all of them to stop. In es, that would also
stop the shell's main interpreter loop, which is just another
function.
--

ISPs are responsible for maintaining the Information Superhighway. They
are not responsible for how you drive.      #include <std_disclaimer.h>