[aclug-L] Re: script to kill

[Tom Hull <thull@xxxxxxxxxxx>]

Carl D Cravens wrote:
> 
> On Wed, 22 Mar 2000, Tom Hull wrote:
> 
> > The traditional Linux ps command used the BSD options, which are completely
> > different from the SVR4 ps option. Someone came up with the idea of writing
> > one program to support both option sets, where the SVR4 options switches
> > are preceded by - while the BSD options don't start with -. The SVR4 ps -e
> > lists _every_ process, which is not what ps e does; the corresponding BSD
> > switch is: ps x
> 
> 'ps e' and 'ps -e' produce the same output on my Debian 2.0 box... except
> that any use of a - also gets...
>    warning: `-' deprecated; use `ps e', not `ps -e'
> 
> Of course, I don't care for the idea that the dash on the flag is
> deprecated... Unix commands should always use dashes to indicate flags.

Right, I remember Linux ps doing that. I never learned the BSD options, so
repeatedly screwed up. I'm running procps version 2.0.4 now, which defaults
to the SVR4 switches (with -), while accepting the BSD switches w/o -. The
"deprecated" warning was just that -- the future is SVR4 switches.

> In this version of ps, the 'x' flag shows processes not attached to a tty,
> not all processes.  'a' shows all processes.  'e' shows the environment
> after the command line (which means it was pointless in my example, but I
> didn't actually look at the ps output).

For my version, ps a does _not_ list all processes; ps ax does. I was hasty
in recommending ps x, but at least it was giving me _more_ output than ps a.

> Like I said, nobody agrees on exactly how ps should work.
> 
> > But that's the same as using ==. You could beat the optional [] with:
> 
> As far as I can tell, == is a numeric compare... I can't get it to match
> anything that isn't a number.

Not sure what you're doing wrong. It's harder to get it to do a numeric
operation (e.g., force numeric by +0). See below.

> > The awk == operator (and other operators) does numeric comparisons if the
> > operands look like numbers; otherwise it does a string compare. E.g.:
> 
> Your script wouldn't produce any output for me, but I've figured out that
> it was a combination of things that caused it to fail... looking at the
> wrong field and calling ps with the wrong option (it wouldn't match init
> because it wasn't looking at all
> 
> I then tried some tests by dropping the PROG thing and adding the text
> directly... but it didn't match because I didn't put quotes around it.
> 
> Of course, a problem with using == is that you have to either trim path
> names off or know whether the program you're looking for was called with a
> full path name or contains any other weirdness (like -bash, etc.)  If the
> name is unique enough, regex match is easier... if it's a common pattern,
> you have to jump through hoops to get exactly what you want.

True, but if you don't anchor the regex, you get positives on substrings,
and if you do anchor it, you have to accommodate the odd cases.

> >   $ echo "1 1ax" | awk '{ print $1 == $2 }'
> >   0
> >   $ echo "1 1.0" | awk '{ print $1 == $2 }'
> >   1
> 
> Sure... 1 may not be numerically equal to 1ax.

Actually, it is numerically equal, at least when treated as a number (cf.,
atol, atof, strtol, etc.):

  $ echo "1 1ax" | awk '{ print ($1+0) == ($2+0) }'
  1

In awk, the + operator always produces a numeric result ("foo" + "bar" == 0),
just as the invisible concatenation operator always produces a string result.

> It's going to produce
> those results whether it can compare strings or not if it interprets any
> variable containing alpha characters as zero.  To prove your point, you
> have to make == match a string, not show that a string doesn't match a
> number.  (Though you don't have to prove your point, since I've seen
> where I was doing it wrong.)

  $ awk 'BEGIN { "foo" == "foo" }' /dev/null
  1
  $ awk 'BEGIN { "foo" == "bar" }' /dev/null
  0

I think the algorithm for (A == B) is:

  a) if A is float and B is float, compare float
  b) else if A or B is float and other is string, but is valid float literal,
     compare float
  c) else compare string

Note that something like "1ax" fails (b), but ("1ax" + 0) evaluates to float
1.0. That's because implicit conversion is only done if the whole string
looks like a float, while explicit conversion uses whatever leading numeric
string may exist (or 0 for none).

> --
> Carl D Cravens (raven@xxxxxxxxxxx)
> Dogs crawl under fences, Software crawls under Windows.
> 
> -- This is the discussion@xxxxxxxxx list.  To unsubscribe,
> visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi

-- 
/*
 *  Tom Hull * thull@xxxxxxxxxxx * http://www.ocston.org/~thull/
 */

-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi