Finding IP addresses+
argo...@my-deja.com
I need to search the hard drives for all the
hard coded IP addresses on the Unix machine.
I need to know every filename.
I am trying:
grep -l "???.???.???.???" ` find /apps -name "*" -type f `
or
grep -l "???.???.???.???" ` find / -name "*" -type f `
But, (I assume) when an executable file is encountered, I get:
/usr/bin/grep: arg list too long
There is also the strings command, and the file command.
I've tried to pipe these commands together along with grep,
but I haven't had any success yet.
Does anyone know a quick solution?
Thanks,
Argosy
Sent via Deja.com http://www.deja.com/
Before you buy.
Ron DuFresne
: HI all,
: I need to search the hard drives for all the
: hard coded IP addresses on the Unix machine.
: I need to know every filename.
You are seeking all IP addresses that might be hidden in any fole on the
systems? Or are you seeking something else? As it is, you will find all
IPs listed in log files <should you as a user have access to them> and all
mail spool files <again, should you have access to them> Let alone any
other files listing one, is this really what you are seeking?
Laterer,
Ron DuFresne
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
Barry Margolin
>I need to search the hard drives for all the
>hard coded IP addresses on the Unix machine.
>
>I need to know every filename.
>
>
>
>grep -l "???.???.???.???" ` find /apps -name "*" -type f `
>or
>grep -l "???.???.???.???" ` find / -name "*" -type f `
That regexp will find all the files containing four sets of three question
marks separated by any single character. It looks to me like you're
confusing shell globbing with regular expressions. To find all the IP
addresses, you want:
'[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]'
>But, (I assume) when an executable file is encountered, I get:
>/usr/bin/grep: arg list too long
Why would you think it has something to do with executable files? The
argument list just contains filenames, doesn't it? The problem is that
there are so many files in /apps that the find command builds an argument
list that's too long for the shell. That's the point of xargs:
find /apps -name '*' -type f | xargs grep -l '[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]'
>There is also the strings command, and the file command.
>
>I've tried to pipe these commands together along with grep,
>but I haven't had any success yet.
I'll bet you forgot about xargs. Doesn't the question about how to search
recursively come up every day or two in one of the Unix newsgroups, and
haven't you seen the common responses before? Did you bother looking
before posting?
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
argo...@my-deja.com
Thanks for responding.
I am trying to find the specific address of the Unix server,
but the brass don't like me to identify it.
Why an executable? When I used to grep for strings on some
systems, it often hung on an executables. I was thinking
that someone might be able to identify how to find
non-executable files from the command prompt. (All files,
except, the executables.) The only way that I could
think of was with a script. You are right, I haven't done
a lot with xargs.
Actually, I save a lot of threads. And I document
commands/solutions in my binders. Thanks for making it
get fuller!
Ciao,
Argosy
In article <8fep7e$d94$1...@nnrp1.deja.com>,
argo...@my-deja.com wrote:
> HI all,
>
> I need to search the hard drives for all the
> hard coded IP addresses on the Unix machine.
>
> I need to know every filename.
>
> I am trying:
>
> grep -l "???.???.???.???" ` find /apps -name "*" -type f `
> or
> grep -l "???.???.???.???" ` find / -name "*" -type f `
>
> But, (I assume) when an executable file is encountered, I get:
> /usr/bin/grep: arg list too long
>
> There is also the strings command, and the file command.
>
> I've tried to pipe these commands together along with grep,
> but I haven't had any success yet.
>
brian hiles
> Hi, Thanks for responding.
> I am trying to find the specific address of the Unix server,
> but the brass don't like me to identify it.
> Why an executable? When I used to grep for strings on some
> systems, it often hung on an executables. I was thinking
> that someone might be able to identify how to find
> non-executable files from the command prompt. (All files,
> except, the executables.) The only way that I could
> think of was with a script. You are right, I haven't done
> a lot with xargs.
> Actually, I save a lot of threads. And I document
> commands/solutions in my binders. Thanks for making it
> get fuller!
> Ciao, Argosy
find . -type f -perm -111 -print
P.S. Always use xargs with the -n option (see the man pages); although
technically not necessary, it _greatly_ speeds up the execution of the
command and still avoids the "arg list too long" diagnostic that made
xargs(1) necessary in the first place.
-Brian
Ron DuFresne
[SNIP]
: Why an executable? When I used to grep for strings on some
: systems, it often hung on an executables. I was thinking
: that someone might be able to identify how to find
: non-executable files from the command prompt. (All files,
: except, the executables.) The only way that I could
: think of was with a script. You are right, I haven't done
: a lot with xargs.
Do a test before the grep, to findout if the file is a binary or lib, or
plain text, we're assuming here you are only interested in the plain old
text pid/conf/process/alias kind of files that might have had this ip
addressing data stored in as the machine came up and or was reconfiged
while up, yes?
Again, unless fo course, you are only trying to determine what IP
addresses have been assinged while up and or coming up, again the most
easily portable way for non-root users to get the info without having to
find how the system calls it's interfaces and ifconfig'ing on those
interfaces is netstat -r
Ben Smithurst
> That regexp will find all the files containing four sets of three question
> marks separated by any single character. It looks to me like you're
> confusing shell globbing with regular expressions. To find all the IP
> addresses, you want:
>
> '[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]\.[0-9][0-9][0-9]'
Uh... that won't match the IP addresses of any of the computers on my
private LAN (e.g. 192.168.91.36). (Though I suppose you were just
correcting his glob rather than giving a 'correct' IP address matching
regex.) More like
[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}
Though that's an extended regex syntax so you'd need egrep (or 'grep -E'
or whatever).
--
Ben Smithurst / b...@scientia.demon.co.uk / PGP: 0x99392F7D
Ken Pizzini
Ben Smithurst <b...@scientia.demon.co.uk> wrote:
>Uh... that won't match the IP addresses of any of the computers on my
>private LAN (e.g. 192.168.91.36). (Though I suppose you were just
>correcting his glob rather than giving a 'correct' IP address matching
>regex.) More like
>
> [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}
That fixes the RE for the sample IP address, but still has the problem
of erroneously matching ``addresses'' like 260357.987.300.000789 .
It is an improvement over the previous RE in that now all legal IP
addresses are now correctly matched, but shares the failing that many
strings which cannot possibly be an IP address are passed through.
Creating a RE to match "any IP address" is not a trivial task
if you _really_ want to get it right, but here's an incremental
improvement (using an ERE again):
(^|[^0-9])([012]?[0-9]?[0-9]\.){3}[012]?[0-9]?[0-9]([^0-9]|$)
This still allows garbage "addresses" like 299.288.277.0 to pass
through, but the number of possible false hits is greatly reduced.
--Ken Pizzini
Craig Peterein
> Creating a RE to match "any IP address" is not a trivial task
> if you _really_ want to get it right, but here's an incremental
> improvement (using an ERE again):
> (^|[^0-9])([012]?[0-9]?[0-9]\.){3}[012]?[0-9]?[0-9]([^0-9]|$)
> This still allows garbage "addresses" like 299.288.277.0 to pass
> through, but the number of possible false hits is greatly reduced.
How about:
byte='(2[0-5][0-5]|1[0-9][0-9]|0?[0-9]?[1-9]|0?[1-9][0-9])'
egrep "(^|[^0-9])($byte\.){3}$byte([^0-9]|$)"
A closer look at $byte, broken out:
byte='(
2[0-5][0-5]
| 1[0-9][0-9]
| 0?[0-9]?[1-9]
| 0?[1-9][0-9]
)'
I tested it and it seems to work. Or did I miss a case?
--
Craig Peterein
mailto:`echo NniO...@aPpcAi.nMet | sed 's/[NOSPAM]//g'`
Neil W Rickert
>How about:
>byte='(2[0-5][0-5]|1[0-9][0-9]|0?[0-9]?[1-9]|0?[1-9][0-9])'
>egrep "(^|[^0-9])($byte\.){3}$byte([^0-9]|$)"
>A closer look at $byte, broken out:
>byte='(
> 2[0-5][0-5]
>| 1[0-9][0-9]
>| 0?[0-9]?[1-9]
>| 0?[1-9][0-9]
>)'
>I tested it and it seems to work. Or did I miss a case?
Does it match 249.249.249.249 ?
Craig Peterein
> Craig Peterein <NniO...@aPpcAi.nMet> writes:
> >I tested it and it seems to work. Or did I miss a case?
>
> Does it match 249.249.249.249 ?
Good catch.
I knew I forgot something. Try it now.
byte='(2[0-4][0-9]|25[0-5]|1[0-9][0-9]|0?[0-9]?[1-9]|0?[1-9][0-9])'
egrep "(^|[^0-9])($byte\.){3}$byte([^0-9]|$)"
--
Thanh
k...@halcyon.com wrote:
> On Wed, 17 May 2000 15:42:28 +0100,
> Ben Smithurst <b...@scientia.demon.co.uk> wrote:
> >Uh... that won't match the IP addresses of any of the computers on my
> >private LAN (e.g. 192.168.91.36). (Though I suppose you were just
> >correcting his glob rather than giving a 'correct' IP address
matching
> >regex.) More like
> >
> > [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}
>
> That fixes the RE for the sample IP address, but still has the problem
> of erroneously matching ``addresses'' like 260357.987.300.000789 .
> It is an improvement over the previous RE in that now all legal IP
> addresses are now correctly matched, but shares the failing that many
> strings which cannot possibly be an IP address are passed through.
>
> if you _really_ want to get it right, but here's an incremental
> improvement (using an ERE again):
> (^|[^0-9])([012]?[0-9]?[0-9]\.){3}[012]?[0-9]?[0-9]([^0-9]|$)
> This still allows garbage "addresses" like 299.288.277.0 to pass
> through, but the number of possible false hits is greatly reduced.
Works great but it would also allow non-IP addresses like 0.1.2.3.4.5.6
to pass through.
Thanh
>
> --Ken Pizzini
Sweth Chandramouli
Craig Peterein <NniO...@aPpcAi.nMet> wrote:
>Neil W Rickert wrote:
>> Craig Peterein <NniO...@aPpcAi.nMet> writes:
>> >I tested it and it seems to work. Or did I miss a case?
>>
>> Does it match 249.249.249.249 ?
>
>Good catch.
>
>I knew I forgot something. Try it now.
>
>byte='(2[0-4][0-9]|25[0-5]|1[0-9][0-9]|0?[0-9]?[1-9]|0?[1-9][0-9])'
>egrep "(^|[^0-9])($byte\.){3}$byte([^0-9]|$)"
to match in perl; I'm fairly certain that it matches all of the cases
and no invalid cases:
chomp ($_[0]);
my $dq_regex = "([01]?[0-9][0-9]?|2([0-4][0-9]|5[0-5]))";
($_[0] =~ m/^(${dq_regex}\.){3}${dq_regex}$/);
I've actually got a fairly robust set of perl functions
for matching/parsing IPv4 addresses and netmasks in a variety of formats,
that I was thinking of posting to CPAN; does anyone know if something like
that already exists? (I spent a fair amount of time looking for such a
module before writing mine, so I _think_ it doesn't, but I never bothered
to just ask.)
-- Sweth.
--
Sweth Chandramouli ; <sw...@sweth.net>
<a href="http://www.sweth.net/legal/disc.html">*</a>
Ken Pizzini
> k...@halcyon.com wrote:
>> Creating a RE to match "any IP address" is not a trivial task
>> if you _really_ want to get it right, but here's an incremental
>> improvement (using an ERE again):
>> (^|[^0-9])([012]?[0-9]?[0-9]\.){3}[012]?[0-9]?[0-9]([^0-9]|$)
>> This still allows garbage "addresses" like 299.288.277.0 to pass
>> through, but the number of possible false hits is greatly reduced.
>
>Works great but it would also allow non-IP addresses like 0.1.2.3.4.5.6
>to pass through.
Yeah; I vacillated over whether to use "[^0-9]" or "[^0-9.]".
Does the sentence:
"My computer's IP address is 1.2.3.4."
contain an IP address? I decided to allow it, with the obvious
resulting breakage.
--Ken Pizzini
Tom Phoenix
> Here's the version I whacked together a while ago
> to match in perl; I'm fairly certain that it matches all of the cases
> and no invalid cases:
>
> chomp ($_[0]);
> my $dq_regex = "([01]?[0-9][0-9]?|2([0-4][0-9]|5[0-5]))";
> ($_[0] =~ m/^(${dq_regex}\.){3}${dq_regex}$/);
Does it match 2130706433? I can telnet to that address; can you? :-)
I can generally find something interesting at this URL, although some
browsers don't work properly with it.
> I've actually got a fairly robust set of perl functions
> for matching/parsing IPv4 addresses and netmasks in a variety of formats,
> that I was thinking of posting to CPAN; does anyone know if something like
> that already exists?
Does Net::DNS do what you want? Although maybe all you need is part of
this long line:
perl -MSocket -lwe 'print +(gethostbyaddr inet_aton(3427256387), AF_INET)[0]'
When something has been needed by a programmer during (more-or-less) every
week since perl came into existence, there's a good chance that it's been
done already. :-) Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
I R A Darth Aggie
Tom Phoenix <root...@redcat.com>, in
<Pine.GSO.4.10.100052...@user2.teleport.com> wrote:
+ On Wed, 24 May 2000, Sweth Chandramouli wrote:
+
+ > Here's the version I whacked together a while ago
+ > to match in perl; I'm fairly certain that it matches all of the cases
+ > and no invalid cases:
+ >
+ > chomp ($_[0]);
+ > my $dq_regex = "([01]?[0-9][0-9]?|2([0-4][0-9]|5[0-5]))";
+ > ($_[0] =~ m/^(${dq_regex}\.){3}${dq_regex}$/);
+
+ Does it match 2130706433? I can telnet to that address; can you? :-)
localhost?
+ I can generally find something interesting at this URL, although some
+ browsers don't work properly with it.
+
+ http://3427256387/
Yahoo!
There's nothing that sez IP #'s have to be quad.dotted in the 0-255 range.
James
--
Consulting Minister for Consultants, DNRC
The Bill of Rights is paid in Responsibilities - Jean McGuire
To cure your perl CGI problems, please look at:
<url:http://www.perl.com/CPAN/doc/FAQs/cgi/idiots-guide.html>
Larry Rosler
100...@user2.teleport.com> on Wed, 24 May 2000 09:08:09 -0700, Tom
Phoenix <root...@redcat.com> says...
...
> I can generally find something interesting at this URL, although some
> browsers don't work properly with it.
>
My browsers insist on filling in my local domain. But they work on the
dotted-quad 204.71.200.67 .
perl -lwe "print join '.' => unpack C4 => pack N => 3427256387"
> > I've actually got a fairly robust set of perl functions
> > for matching/parsing IPv4 addresses and netmasks in a variety of formats,
> > that I was thinking of posting to CPAN; does anyone know if something like
> > that already exists?
>
> Does Net::DNS do what you want? Although maybe all you need is part of
> this long line:
>
> perl -MSocket -lwe 'print +(gethostbyaddr inet_aton(3427256387), AF_INET)[0]'
But the reverse DNS on two of my systems (HP-UX and Windows NT, but on
the same intranet) didn't resolve either this form or the dotted-quad
form. Hmmm...
Mini-crusade, probably doomed ab initio:
When the one-liner Perl command doesn't include shell metacharacters,
why not use double-quotes instead of single-quotes, for portability to
DOS shells, as I did in my example above? It makes it easier to copy-
and-paste, instead of having to edit the quotes.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
l...@hpl.hp.com
Abigail
++ On Wed, 24 May 2000 09:08:09 -0700,
++ Tom Phoenix <root...@redcat.com>, in
++ <Pine.GSO.4.10.100052...@user2.teleport.com> wrote:
++ + On Wed, 24 May 2000, Sweth Chandramouli wrote:
++ +
++ + > Here's the version I whacked together a while ago
++ + > to match in perl; I'm fairly certain that it matches all of the cases
++ + > and no invalid cases:
++ + >
++ + > chomp ($_[0]);
++ + > my $dq_regex = "([01]?[0-9][0-9]?|2([0-4][0-9]|5[0-5]))";
++ + > ($_[0] =~ m/^(${dq_regex}\.){3}${dq_regex}$/);
++ +
++ + Does it match 2130706433? I can telnet to that address; can you? :-)
++
++ localhost?
++
++ + I can generally find something interesting at this URL, although some
++ + browsers don't work properly with it.
++ +
++ + http://3427256387/
++
++ Yahoo!
++
++ There's nothing that sez IP #'s have to be quad.dotted in the 0-255 range.
No, but the RFC for URLs says that if a numerical address is used, it
shall have exactly 3 dots.
http://3427256387/ doesn't match the grammar of the RFC.
Abigail
Abigail
++ In article <Pine.GSO.4.10.10005240846240.23375-
++ 100...@user2.teleport.com> on Wed, 24 May 2000 09:08:09 -0700, Tom
++ Phoenix <root...@redcat.com> says...
++
++>perl -MSocket -lwe 'print +(gethostbyaddr inet_aton(3427256387), AF_INET)[0]'
++
++ Mini-crusade, probably doomed ab initio:
++
++ When the one-liner Perl command doesn't include shell metacharacters,
++ why not use double-quotes instead of single-quotes, for portability to
++ DOS shells, as I did in my example above? It makes it easier to copy-
++ and-paste, instead of having to edit the quotes.
That would require to know what the all the different shell
metacharacters are, from all different shells, and in which
circumstances they are meta or not. In the one-liner above, () and []
are, under the appropriate conditions, shell meta characters.
Abigail
Brandon Metcalf
> Does it match 2130706433? I can telnet to that address; can you? :-)
>
> I can generally find something interesting at this URL, although some
> browsers don't work properly with it.
>
I tried searching a few places but didn't come up with anything. How
do these purely numerical addresses translate to the octet addresses?
Thanks,
-brandon
Dave Vandervies
Write it in hex, and then just put dots between the octets. Converting
the individual octets from hex back to decimal might make it easier to
recognize.
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
I love that the net is responsible for the propagation of the ILOVEYOU worm,
according to Microsoft. In much the same manner that air is responsible for
the propagation of bullets. -D. Joseph Creighton in the Scary Devil Monastery
Andrew N. McGuire
+ In article <8ghjgl$k4l$1...@spinner.corpeast.baynetworks.com>,
+ Brandon Metcalf <bmet...@baynetworks.com> wrote:
+ >root...@redcat.com writes:
+ >
+ > > Does it match 2130706433? I can telnet to that address; can you? :-)
+ > >
+ > > I can generally find something interesting at this URL, although some
+ > > browsers don't work properly with it.
+ > >
+ > > http://3427256387/
+ >
+ >I tried searching a few places but didn't come up with anything. How
+ >do these purely numerical addresses translate to the octet addresses?
+
+ Write it in hex, and then just put dots between the octets. Converting
+ the individual octets from hex back to decimal might make it easier to
+ recognize.
Huh? 3427256387 in hex is 0xcc47c843!!!
This will do the job:
#!/usr/bin/perl -w
use strict;
my $dec_addr = 3427256387;
my $addr = pack('i10', $dec_addr);
my @octets = unpack('C4', $addr);
print +join('.', reverse(@octets)), "\n";
Outputs:
204.71.200.67
A lookup yields:
sh-2.03$ nslookup 3427256387
Server: elpxy01.ce.mediaone.net
Address: 24.131.128.11
Name: www2.yahoo.com
Address: 204.71.200.67
That looks OK to me.
Regards,
anm
--
/*-------------------------------------------------------.
| Andrew N. McGuire |
| anmc...@ce.mediaone.net |
`-------------------------------------------------------*/
Ben Smithurst
> I tried searching a few places but didn't come up with anything. How
> do these purely numerical addresses translate to the octet addresses?
An IPv4 address is a 32 bit number. How you represent it is your
business. It's just conventional with IPv4 address to print the four
bytes as decimal numbers separated by dots.
Dave Vandervies
Andrew N. McGuire <anmc...@ce.mediaone.net> wrote:
>On 24 May 2000, Dave Vandervies wrote:
>
>+ In article <8ghjgl$k4l$1...@spinner.corpeast.baynetworks.com>,
>+ Brandon Metcalf <bmet...@baynetworks.com> wrote:
>+ > > I can generally find something interesting at this URL, although some
>+ > > browsers don't work properly with it.
>+ > >
>+ > > http://3427256387/
>+ >
>+ >I tried searching a few places but didn't come up with anything. How
>+ >do these purely numerical addresses translate to the octet addresses?
>+
>+ Write it in hex, and then just put dots between the octets. Converting
>+ the individual octets from hex back to decimal might make it easier to
>+ recognize.
>
>Huh? 3427256387 in hex is 0xcc47c843!!!
Write in hex:
cc47c843
Put dots between the octets:
cc.47.c8.43
Convert the individual octets back to decimal to aid recognition:
204.71.200.67
>This will do the job:
>
<perl script snipped>
>
>Outputs:
>
>204.71.200.67
Looks the same to me.
dave
--
Dave Vandervies
dj3v...@student.math.uwaterloo.ca
If ignorance is bliss, why aren't more people happy?
Michael Sternberg
> Tom Phoenix <root...@redcat.com> says...
> > http://3427256387/
> My browsers insist on filling in my local domain. But they work on the
> dotted-quad 204.71.200.67 .
> perl -lwe "print join '.' => unpack C4 => pack N => 3427256387"
How about the following, which also gives a bit of context and shows if the
IP is firmly set up and registered:
% nslookup 3427256387
Server: localhost
Address: 127.0.0.1
Name: www2.yahoo.com
Address: 204.71.200.67
> When the one-liner Perl command doesn't include shell metacharacters,
> why not use double-quotes instead of single-quotes, for portability to
> DOS shells, as I did in my example above? It makes it easier to copy-
> and-paste, instead of having to edit the quotes.
Not good; not just for political reasons, but for "maintenance". Even if
there are no meta-characters to begin with (meta for the shells in
question, mind you) -- as soon as you try to add some variable handling in
refinements, the " stand in the way.
Regards,
--
Michael Sternberg, Dipl. Phys. | Uni-GH Paderborn
http://www.phys.uni-paderborn.de/~stern/ | FB6 Theoretische Physik
phone: +49-(0)5251-60-2329 fax: -3435 | 33098 Paderborn, Germany
"Who disturrrbs me at this time?" << Zaphod Beeblebrox IV >> <*>
Andrew N. McGuire
+ In article <Pine.LNX.4.21.000524...@hawk.ce.mediaone.net>,
+ Andrew N. McGuire <anmc...@ce.mediaone.net> wrote:
+ >On 24 May 2000, Dave Vandervies wrote:
+ >
+ >+ In article <8ghjgl$k4l$1...@spinner.corpeast.baynetworks.com>,
+ >+ Brandon Metcalf <bmet...@baynetworks.com> wrote:
+ >+ > > I can generally find something interesting at this URL, although some
+ >+ > > browsers don't work properly with it.
+ >+ > >
+ >+ > > http://3427256387/
+ >+ >
+ >+ >I tried searching a few places but didn't come up with anything. How
+ >+ >do these purely numerical addresses translate to the octet addresses?
+ >+
+ >+ Write it in hex, and then just put dots between the octets. Converting
+ >+ the individual octets from hex back to decimal might make it easier to
+ >+ recognize.
+ >
+ >Huh? 3427256387 in hex is 0xcc47c843!!!
+
+ Write in hex:
+ cc47c843
+
+ Put dots between the octets:
+ cc.47.c8.43
+
+ Convert the individual octets back to decimal to aid recognition:
+ 204.71.200.67
+
+ >This will do the job:
+ >
+ <perl script snipped>
+ >
+ >Outputs:
+ >
+ >204.71.200.67
+
+ Looks the same to me.
Ah, OK, I see what you mean, sorry your wording lost me,
as there are no real 'octets' in an hex number. But yes
I suppose you could use binary/hex etc. I initially used
binary, becuase I can 'think' better in binary than I can
hex. I know that is backwards, but its true.
Regards,
anm
--
/*-------------------------------------------------------.
| Andrew N. McGuire |
| andrew....@walgreens.com |
`-------------------------------------------------------*/
Larry Rosler
Abigail <abi...@arena-i.com> says...
Are these the appropriate conditions? I am referring only to what
characters are 'meta' within double-quotes. According to sh-posix(1),
Inside double quote marks (""), parameter and command substitution
occurs and \ quotes the characters \, `, ", and $.
That is a limited set of metacharacters indeed! The only significant
one is '$', and note that there are no Perl scalars in the expression I
was referring to.