The macosxhints Forums - if string contains?

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- UNIX - General (http://hintsforums.macworld.com/forumdisplay.php?f=16)

- - if string contains? (http://hintsforums.macworld.com/showthread.php?t=90151)

Quote:

Originally Posted by baf (Post 473457)

No my first script rejects those. If you look in the script the address it checks is IN the script not taken from the commandline. Thats because gspragues:s code was like that. So you have checked 100.1.1.100 a number of times.

Hmm, oh yeah... i never read it closely (just copy/paste/execute).
Okay.

Quote:

Originally Posted by baf (Post 473457)

One can also argue if your script really is a bash script or a wrapper for awk.

I was trying to setup a real #!/usr/bin/awk -f type deal... but I can't seem to figure out
how to get awk to directly apply its pattern processing to a given command-line argument.
Awk is hell-bent on reading files (pathname), and more-than-willing to munch up its stdin.
But forcing it to feed upon command line args (for pattern processing) is nigh impossible.

If anyone here can show me the trick, here's what I have so far...

Code:

#!/usr/bin/awk -f

BEGIN { FS = "." }

{

        if(NF!=4 || $0~/[^0-9.]/) exit 1

        for(i=1;i<5;i++) { if($i>255) exit 2

                if(1>length($i) || length($i)>3) exit 3

                if($i>7 && $i~/^0/) exit 4

}

But, we have to call that version by echoing into it:
echo 12.34.56.78 | okip3

instead of a simple arg:
okip3 12.34.56.78

I tried a bunch of stuff like:

- (the dash being an arg symbolizing stdin)
"/dev/stdin"
ARGV[1]
and even a here-string:
<<<"$1"

Nothing worked. :(

Yeah I tried to do that too :mad: and it didn't want to do it for me either.

How about this

Code:

#! /usr/bin/awk -F. -f

BEGIN{

    "/bin/echo " ARGV[1] |getline

    if(NF!=4 || $0~/[^0-9.]/) exit 1

    for(i=1;i<5;i++) { if($i>255) exit 2

        if(1>length($i) || length($i)>3) exit 3

        if($i>7 && $i~/^0/) exit 4

    }

}

Oh and a new perl version:

Code:

baf@bengt-arne-fjellners-computer ~

$ cat ttt.pl

#!/usr/bin/perl

@o=$ARGV[0]=~/\G(\d+)(?:\.|$)/gc;

exit 1 if @o!=4;

map{exit 1 if $_>255||/^0\d/}@o



baf@bengt-arne-fjellners-computer ~

$ wc -c ttt.pl

      99 ttt.pl

Quote:

Originally Posted by baf (Post 473499)

#! /usr/bin/awk -F. -f
BEGIN{
"/bin/echo " ARGV[1] |getline
:D

Yeah, that looks about like what it would take. [i'll test it in a minute... thanks!!!]
I think from reading various docs that variations of awk (such as gawk and mawk)
may have that type of kluge condensed into a single option... but not awk itself.

Though I forgot to mention it, I did play around with some (of the eight) variations
of getline... but didn't hit upon the magic you found. I note that -- in addition to that
line you added -- the "GNU Awk User's Guide" seems to suggest that such code should
be shortly followed by:

close("/bin/echo ")

so -- all in all -- it costs almost 50 extra chars, just to read the darn argument. :D

I'll need to run some tests to be sure... maybe it was that "close()" part that prevented
my attempts from working.

Thanks again.

Quote:

Originally Posted by baf (Post 473499)

Code:

baf@bengt-arne-fjellners-computer ~

$ cat ttt.pl

#!/usr/bin/perl

@o=$ARGV[0]=~/\G(\d+)(?:\.|$)/gc;

exit 1 if @o!=4;

map{exit 1 if $_>255||/^0\d/}@o



baf@bengt-arne-fjellners-computer ~

$ wc -c ttt.pl

      99 ttt.pl

99? :eek: That's sick.

And I could make it some 4 or 5 characters shorter IF I totally gave up readability. No newlines and some less spaces but thats going too far. I'm very happy to get below 100 chars (even if it's JUST below).

Quote:

Originally Posted by baf (Post 473534)

And I could make it some 4 or 5 characters shorter
IF I totally gave up readability.

:rolleyes: Oh but, we wouldn't want to do that.
After all... "readability" is Perl's strong point! :D :D :D

I totally agree with that. Ones I wrote a program. Went to lunch. Came back and almost wondered "who wrote this? What does it mean?" :D :D :D

Oh and to use close in awk you have to use the exact same sequence of characters as when you opened it. So for:
"/bin/echo " ARGV[1] |getline
You would have to do:
close("/bin/echo " ARGV[1])
so that's even more characters....

Tip: variables!!

C="/bin/echo " ARGV[1]
C |getline
close(C)

And if someone else wants to use that trick and have more code then you should really do:
delete ARGV[1]
otherwise awk will try to read the file 10.1.1.10 or whatever....

I have tested this and it really seems to close the pipe when it should.
Hmm readability what does that mean :D:D

Quote:

Originally Posted by baf (Post 473545)

Oh and to use close in awk you have to use the exact same sequence of characters as when you opened it. So for:
"/bin/echo " ARGV[1] |getline
You would have to do:
close("/bin/echo " ARGV[1])
so that's even more characters....

As luck would have it, I was just returning to post about precisely that:
The built-in "echo " will do just fine thanks! We needn't bother with /bin,
when Bash (or any shell I imagine) has its own internal echo mechanism.

[or am i mistakenly ignoring scenarios where scripts run sans a terminal?
doesn't matter... right... or ?]

-

BTW, I learned that my previous attempts with "echo " ARGV[1] |getline had failed
because I was doing that part inside BEGIN { }... and then trying to use that read
line inside a second set of { braces }. awk doesn't preserve that 'got line' across
to the next group of braces (it seems).

Also... since your version works *without* close(), I think it's okay to skip that part.
Not sure but -- since awk doesn't send an error about it -- i think it's fine to leave it out.
Or wait...

Quote:

I have tested this and it really seems to close the pipe when it should.

Can you explain that part a little? [sounds like maybe close() is a Good Thing™ to do.]

--

Finally, what is the final consensus about leading zeros in terms of a little tool like
the one we have been building. Is it appropriate for our tool to reject *all* leading
zero attempts? Or perhaps should we allow just the 000 thru 007 range (like i did),
or should we allow *all* leading zero fields (as long as no other violation occurs),
with a philosophy that: well... the user must know what they want if they do that.

Whaddya think? :confused:

Use this code:

Code:

#! /usr/bin/awk -F. -f

BEGIN{

    C="/bin/echo " ARGV[1]

    delete ARGV[1]

    C |getline

    #close(C)

    if(NF!=4 || $0~/[^0-9.]/) exit 1

    for(i=1;i<5;i++) { if($i>255) exit 2

        if(1>length($i) || length($i)>3) exit 3

        if($i>7 && $i~/^0/) exit 4

    }

}

{ exit 0 }

and call it as:
xxxx 10.1.1.10 -
(don't miss that hyphen and for this it must be /bin/echo) Now it doesn't terminate until you press enter. In another terminal/window do:
ps axco command |grep echo
And you will find a running echo process
press enter and it dies.
Now remove the comment mark before "close" and repeat.
No extra process. That's what I mean. But really in a short program like this it isn't needed but it's good practise to always use it. In a bigger program if you don't do close and later do echo again (with the same parameters) it would "reuse" the same process and fail. Also you could have a bunch of unnecessary processes.

Quote:

Originally Posted by baf (Post 473504)

Oh and a new perl version:

Code:

$ wc -c ttt.pl

      99 ttt.pl

Not too shabby, but you fail to reject trailing periods. How about:

Code:

ronk@sexy:bin(0)$ cat ipok

#!/usr/bin/perl

$_=$ARGV[0];s/[1-9]\d*/$&<256?0:1/ge;exit($_ ne"0.0.0.0");

ronk@sexy:bin(0)$ ipok 1.2.3.4

ronk@sexy:bin(0)$ ipok 1.2.3.4.

ronk@sexy:bin(1)$ ttt.pl 1.2.3.4

ronk@sexy:bin(0)$ ttt.pl 1.2.3.4.

ronk@sexy:bin(0)$ wc -c ipok

      75 ipok

(The '(0)' or '(1)' you see at the end of my shell prompt is the status from the previous command.)

About the new version "OOps"
And about yours "I zink we has a winner"

Quote:

Originally Posted by Hal Itosis (Post 473594)

Finally, what is the final consensus about leading zeros in terms of a little tool like
the one we have been building. Is it appropriate for our tool to reject *all* leading zero attempts?

I think it depends on what the user is planning to do with an IP address that passes.

I did a search through all the RFCs, looking for every occurrence of the word "dotted". The RFCs seem to be unanimous, in that IPv4 addresses are dotted decimal, while IPv6 addresses are always hex. Typical phraseology, repeated over and over again in the RFCs, is something like:

Quote:

We noted that the getipnodebyname() function must allow the name
argument to be either a node name or a literal address string (i.e.,
a dotted-decimal IPv4 address or an IPv6 hex address).

Several of the RFCs give the IP address of VENERA.ISI.EDU as an example, showing it with and without leading zeroes, but it remains decimal (not octal) even with leading zeroes. (The actual address does change over time. It was apparently originally on the 10.x.x.x subnet, which is no longer world-routable.) I think the purpose of the example is to show that it's OK to pad the address to a fixed width so that printed tables will format nicely.

However, when an IP address is used as part of a URI, they're emphatically opposed to the notion that any reasonable format will do. One issue is the lack of standardization: some sites will interpret a leading zero to mean octal, and others will treat it still as decimal. That means that the same exact URI means different things at different hosts, making routing a nightmare. (Yeah, yeah, different DNS servers might map the same FQDN to different IP addresses, but at least they all agree about which FQDN they're mapping.) Worse, some sites will interpret a leading 0x to mean hexadecimal, while others will interpret the non-digit to mean it's not a numeric address at all, and try to resolve it as a Fully Qualified Domain Name.

All of which leads to some hairy security issues. The use of non-canonical dotted IP addresses (dotted octal, dotted hex, dotted decimal with leading zeroes) opens up some potential attack vectors.

It seems to me to be best to nip the problem in the bud by rejecting non-canonical IP address outright. The worst that will happen is that our subroutine rejects it as an IP address, forcing the caller to look it up using DNS, and that search will probably fail. (If it really could be interpreted as an IP address, its Top Level Domain will be invalid. None of the extant TLDs are numeric or begin with 0x.)

A case could be made for allowing the leading zeroes in situations where you know the string is intended to be an IP address... except that I can't think of many such situations. Utilities like ping will happily accept domain name in lieu of an IP address. The only places I can think of where it has to be an IP address is in specifying a Domain Name Server, or in configuring your local system. In both of those cases, it's not onerous to require the user to use a canonical IP address.

And besides, the octal/decimal ambiguity is enough to make me think that a person prepending extra zeroes in an IP address does not know what they're doing. Are they even aware of the ambiguity? Can they be certain how the address will be interpreted? If so, how? If not, why are they doing it?

Quote:

Originally Posted by baf (Post 473399)

Oh I agree with that I was checking what implementations not standards allow. And from rfc3986

Code:

A host identified by an IPv4 literal address is represented in

dotted-decimal notation (a sequence of four decimal numbers in the range 0 to 255, separated by "."),

as described in [RFC1123] by reference to [RFC0952].

Note that other forms of dotted notation may be interpreted on some platforms,

as described in Section 7.4,

but only the dotted-decimal form of four octets is allowed by this grammar.



   IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet



   dec-octet   = DIGIT                 ; 0-9

               / %x31-39 DIGIT         ; 10-99

               / "1" 2DIGIT            ; 100-199

               / "2" %x30-34 DIGIT     ; 200-249

               / "25" %x30-35          ; 250-255

The last part to me implies that leading zeros are forbidden in an URI.

I still read this part of rfc3986 as forbidding leading zeros in an uri/url concur? oppose?

Quote:

Originally Posted by baf (Post 473595)

Use this code [ . . . ] and call it as:
xxxx 10.1.1.10 -
(don't miss that hyphen and for this it must be /bin/echo)
Now it doesn't terminate until you press enter.
In another terminal/window do:
ps axco command |grep echo
And you will find a running echo process
press enter and it dies.
Now remove the comment mark before "close" and repeat.
No extra process. That's what I mean.

But really in a short program like this it isn't needed but it's good practise to always use it. In a bigger program if you don't do close and later do echo again (with the same parameters) it would "reuse" the same process and fail. Also you could have a bunch of unnecessary processes.

Great explanation Bengt... it helped a lot.
Working through the first part, I looked at the process status in more detail:

Code:

$ ps axcru |sed -E '1p;/.*(awk|echo)/!d'

USER       PID %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND

halito   34294   0.0  0.0   599804    536 s001  S+    2:32PM   0:00.00 awk

halito   34295   0.0  0.0        0      0 s001  Z+    2:32PM   0:00.00 (echo)

There it shows awk as sleeping, and "(echo)" as zombied!

As you mentioned, in this little script -- where we bail out virtually as soon as we "BEGIN" -- and
also make no further attempts to access that process/pipe... we can omit explicitly stating all the
close and delete business. Super. Thanks for making it more understandable.

Quote:

Originally Posted by ganbustein (Post 473601)

How about:

Code:

$ cat ipok

#!/usr/bin/perl

$_=$ARGV[0];s/[1-9]\d*/$&<256?0:1/ge;exit($_ ne"0.0.0.0");

$ wc -c ipok

      75 ipok

WOW! That is "sexy". (impressively so)

Quote:

Originally Posted by ganbustein (Post 473611)

I did a search through all the RFCs . . .

I won't quote the entire text there, but every word was much appreciated.
Thanks for weighing in again.

Being that it makes more sense to either reject all or accept all leading-zero cases,
I therefore removed the awk line which accepted leading zeros on numbers less than 8.
[indeed, such code behavior could more easily cause confusion than add convenience.]

I tried to reduce things a bit more, by not calling length() repeatedly.

So here then is my (unsexy, 200-character) latest version:

Code:

#!/usr/bin/awk -F. -f

BEGIN {

        "echo " ARGV[1] |getline

        if(NF!=4 || $0~/[^0-9.]/) exit 1

        for(x=1;x<5;x++) { y=length($x)

                if($x>255) exit 2

                if(1>y || y>3) exit 3

                if(y>1 && $x~/^0/) exit 4

        }

}

Quote:

Originally Posted by baf (Post 473614)

I still read this part of rfc3986 as forbidding leading zeros in an uri/url concur? oppose?

Finder didn't seem to complain (when doing a ⌘K on my LAN).
Typing afp://192.168.001.010/ in the server address field
(plus a password) brings up a message saying

"Connecting to afp://192.168.001.010/"

:)

It worked. [though netstat still shows it as 192.168.1.10]