Find Mac Address

[chellappa]

hi all
I need to write a program to find mac address of a my computer using
libaries, is
this possible? How?
thanks

[pemo]

"chellappa" <N.*********@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

hi all
I need to write a program to find mac address of a my computer using
libaries, is
this possible? How?
thanks

Best to ask this in an os or networking specific group. Std c knows nothing
about MAC addresses

[Keith Thompson]

"chellappa" <N.*********@gmail.com> writes:

I need to write a program to find mac address of a my computer using
libaries, is
this possible? How?

Not in standard C. Try a newsgroup that's specific to your system.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Zara]

On 9 Nov 2005 22:51:13 -0800, "chellappa" <N.*********@gmail.com>
wrote:

hi all
I need to write a program to find mac address of a my computer using
libaries, is
this possible? How?
thanks

It is OS-dependent, please ask on the group related to development on
your OS.

Regards,

-- Zara

[David Resnick]

chellappa wrote:
[... usual off topic crap that he writes ...]

/| /| | |
||__|| | Please do |
/ O O\__ NOT |
/ \ feed the |
/ \ \ trolls |
/ _ \ \ ______________|
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ \ __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________

-David
<OT>who is still wishing google groups, which I sadly use to read
this stuff, would implement killfiles</OT>

[SM Ryan]

"chellappa" <N.*********@gmail.com> wrote:
# hi all
# I need to write a program to find mac address of a my computer using
# libaries, is
# this possible? How?

I don't know about others, but on unices there's a command line to
do this, such as ifconfig. You can do something like
#ifdef __DARWIN__
system("ifconfig >config.txt");
FILE *f = fopen("config.txt","rt");
...read and parse the file f...
fclose(f);
#endif
#ifdef __some other system__
...
#endif
...

Some bits of the system status are not easily available in
libraries, and the best way is to run a command line and parse
the output.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Who's leading this mob?

[Walter Roberson]

In article <11*************@corp.supernews.com>,
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

I don't know about others, but on unices there's a command line to
do this, such as ifconfig. You can do something like
#ifdef __DARWIN__
system("ifconfig >config.txt");
FILE *f = fopen("config.txt","rt");
...read and parse the file f...
fclose(f);
#endif

And if I place something else named "ifconfig" earlier on my
search path?
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

[Chris Torek]

>In article <11*************@corp.supernews.com>,

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

... You can do something like
#ifdef __DARWIN__
system("ifconfig >config.txt");
FILE *f = fopen("config.txt","rt");
...read and parse the file f...
fclose(f);
#endif

In article <dl**********@canopus.cc.umanitoba.ca>
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:And if I place something else named "ifconfig" earlier on my
search path?

Even worse, suppose it actually works. What is "the" MAC address
on my machine here?

% ifconfig -a | grep ether
link type ether 0:0:f8:2:75:90 mtu 1500 speed 10Mbps
link type ether 0:a:5e:5:b3:fd mtu 1500 speed 100Mbps
link type ether 0:b0:d0:d8:b3:27 mtu 1500 speed 100Mbps

(There are three Ethernet cards, for the three separate networks
this machine is on.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Randy Howard]

David Resnick wrote
(in article
<11*********************@g43g2000cwa.googlegroups. com>):

<OT>who is still wishing google groups, which I sadly use to read
this stuff, would implement killfiles</OT>

Continued OT: I just wish that Google would archive only, and
cease providing their broken interface to NNTP directly.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Skarmander]

Randy Howard wrote:

David Resnick wrote
(in article
<11*********************@g43g2000cwa.googlegroups. com>):

<OT>who is still wishing google groups, which I sadly use to read
this stuff, would implement killfiles</OT>

Continued OT: I just wish that Google would archive only, and
cease providing their broken interface to NNTP directly.

And end the endless September? Who'd pick up the torch?

S.

[Keith Thompson]

Randy Howard <ra*********@FOOverizonBAR.net> writes:

David Resnick wrote
(in article
<11*********************@g43g2000cwa.googlegroups. com>):

<OT>who is still wishing google groups, which I sadly use to read
this stuff, would implement killfiles</OT>

Continued OT: I just wish that Google would archive only, and
cease providing their broken interface to NNTP directly.

Or, better yet, that they'd *fix* their broken NNTP interface. It was
actually decent before the introduced the current "beta" (or at least
it didn't have the horrendous problems that the current version
introduced). I have no problem with a web interface to NNTP, as long
as it's done right.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[SM Ryan]

Chris Torek <no****@torek.net> wrote:

Must be hard to have a leaky killfile.

# >In article <11*************@corp.supernews.com>,
# >SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
# >>... You can do something like
# >> #ifdef __DARWIN__
# >> system("ifconfig >config.txt");
# >> FILE *f = fopen("config.txt","rt");
# >> ...read and parse the file f...
# >> fclose(f);
# >> #endif
#
# In article <dl**********@canopus.cc.umanitoba.ca>
# Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
# >And if I place something else named "ifconfig" earlier on my
# >search path?

How about if you place something else named "cc" in your search
path? If you choose to sabotage your own system, do you really
expect me to clean up your mess?

# Even worse, suppose it actually works. What is "the" MAC address
# on my machine here?

How would a library interface avoid this issue any better than
a command line?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
No pleasure, no rapture, no exquisite sin greater than central air.

[Keith Thompson]

[obnoxious '#' quoting character corrected yet again]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

Chris Torek <no****@torek.net> wrote:

Must be hard to have a leaky killfile.

In article <11*************@corp.supernews.com>,
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
>... You can do something like
> #ifdef __DARWIN__
> system("ifconfig >config.txt");
> FILE *f = fopen("config.txt","rt");
> ...read and parse the file f...
> fclose(f);
> #endif

In article <dl**********@canopus.cc.umanitoba.ca>
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

And if I place something else named "ifconfig" earlier on my
search path?

How about if you place something else named "cc" in your search
path? If you choose to sabotage your own system, do you really
expect me to clean up your mess?

Even worse, suppose it actually works. What is "the" MAC address
on my machine here?

How would a library interface avoid this issue any better than
a command line?

I don't think Chris implied that a library interface would be better
than a command line. His point, I think, is that there is no solution
in standard C, and therefore the whole thing is off-topic. If this
discussion were taking place in a more appropriate newsgroup, all the
issues of whether ifconfig is in your path could be discussed in
detail.

(BTW, "rt" isn't a valid mode for fopen().)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Walter Roberson]

In article <11*************@corp.supernews.com>,
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

# >In article <11*************@corp.supernews.com>,
# >SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
# >>... You can do something like
# >> #ifdef __DARWIN__
# >> system("ifconfig >config.txt");
# >> FILE *f = fopen("config.txt","rt");
# >> ...read and parse the file f...
# >> fclose(f);
# >> #endif # In article <dl**********@canopus.cc.umanitoba.ca>
# Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:
# >And if I place something else named "ifconfig" earlier on my
# >search path? How about if you place something else named "cc" in your search
path? If you choose to sabotage your own system, do you really
expect me to clean up your mess?

The code is presumably not just for system administrators to run.
If run by a user, the program should still work. Users might have
just about anything on their path, with no intention of
sabotaging the system.

For example, system() on most unix systems fires up a shell, and that
shell might or might not run the user's shell init, leading
to the possibility that where the system() command sees
"ifconfig" on the command line, it might possibly invoke a
user-established alias (e.g., ifconfig -ia ) because that
just happens to be how the user most often users ifconfig .

A program that breaks based upon something innocent that a user
accidently does in a seemingly unrelated facility, is not
a robust program.

If you are going to down as far as __DARWIN__ then you can
take the next step and have the system() command refer to
an explicit path to darwin's OS-provided ifconfig . If
someone replaces their OS-provided ifconfig, then that's one thing,
but a program intended for user invocation should not (without
good reason) rely upon the uncertain environment that happens to
be provided by the user.

Another example: if the user happens to be cd'd into an
appropriate place in a source tree, then "ifconfig" might happen to
be the name of a local subdirectory, and thus not be executable.
A program that breaks because of something like that is not, IMHO,
a well written program.
--
Programming is what happens while you're busy making other plans.

[Netocrat]

Walter Roberson wrote:
[attributions and quoting simplified and re-ordered]

SM Ryan wrote:

... You can do something like
#ifdef __DARWIN__
system("ifconfig >config.txt");
FILE *f = fopen("config.txt","rt");
...read and parse the file f...
fclose(f);
#endif
And if I place something else named "ifconfig" earlier on my search path?

[...] Another example: if the user happens to be cd'd into an appropriate
place in a source tree, then "ifconfig" might happen to be the name of a
local subdirectory, and thus not be executable. A program that breaks
because of something like that is not, IMHO, a well written program.
If the program is run in a read-only directory the code will also fail.

As well as that, the name of the temporary file ("config.txt") is common
and writing to that file in the current directory may overwrite an
existing config file; the program should make use of tmpfile() if it or
C99 is available, or an equivalent.

<OT>On a Unix-based system such as Darwin the popen() function likely
exists which provides the desired functionality without need to create a
file.</OT>
If you are going to down as far as __DARWIN__ then you can
take the next step and have the system() command refer to an explicit
path to darwin's OS-provided ifconfig .

Or better yet, call the OS's network functions directly. C isn't a
shell-scripting language, even though it can be used to implement one.

--
http://members.dodo.com.au/~netocrat

[Skarmander]

Netocrat wrote:

Walter Roberson wrote:

[parsing the output of ifconfig to determine a MAC address]

If you are going to down as far as __DARWIN__ then you can
take the next step and have the system() command refer to an explicit
path to darwin's OS-provided ifconfig .

Or better yet, call the OS's network functions directly. C isn't a
shell-scripting language, even though it can be used to implement one.

"Simply" calling the OS functions sounds like a better idea than it is.
The reason many resort to such bletcherous hacks as parsing the output
of ifconfig is that this is *still* more portable and reliable than
trying to use the ioctl-of-the-month of whatever version of whatever
operating system we're compiling for. You'll have to leave POSIX town
for that and enter the system call jungle.

Ideally the relevant parts of ifconfig and assorted functionality would
be turned into a cross-platform library, since you're going to be
duplicating ifconfig functionality anyway. In practice, there doesn't
seem to be enough need for this sort of thing to inspire someone to do it.

S.

[Netocrat]

On Fri, 11 Nov 2005 19:42:30 +0100, Skarmander wrote:

Netocrat wrote:

Walter Roberson wrote: [parsing the output of ifconfig to determine a MAC address]

If you are going to down as far as __DARWIN__ then you can
take the next step and have the system() command refer to an explicit
path to darwin's OS-provided ifconfig .

Or better yet, call the OS's network functions directly. C isn't a
shell-scripting language, even though it can be used to implement one.

"Simply" calling the OS functions sounds like a better idea than it is.

Portability isn't as much of an issue as you imply in this case since the
OS is already specified as DARWIN.
The reason many resort to such bletcherous hacks as parsing the output
of ifconfig is that this is *still* more portable and reliable than
trying to use the ioctl-of-the-month of whatever version of whatever
operating system we're compiling for. You'll have to leave POSIX town
for that and enter the system call jungle.

I won't start an off-topic debate on the portability of the ifconfig
command (afaik not standardised by POSIX either) vs OS/library functions.

I will say that such an approach in general is very unidiomatic C and the
assumption of the availability and format of a non-standard external
command is IMO very dubious not least because of the issues Walter raised.
From the point of view of Standard C, the ifconfig command could do
anything, if it even exists.

Such an approach is far better suited to a scripting language, and I
second the "bletcherous" description.

When developing a C application that needs to run on multiple systems and
rely on this functionality, and a portable library doesn't exist as you
seem to believe is true in this case, better to enter the jungle for each
system as required. It's worth the extra effort to do the job properly.

[...]
--
http://members.dodo.com.au/~netocrat

[Skarmander]

Netocrat wrote:

On Fri, 11 Nov 2005 19:42:30 +0100, Skarmander wrote:

Netocrat wrote:

Walter Roberson wrote:
[parsing the output of ifconfig to determine a MAC address]

If you are going to down as far as __DARWIN__ then you can
take the next step and have the system() command refer to an explicit
path to darwin's OS-provided ifconfig .

Or better yet, call the OS's network functions directly. C isn't a
shell-scripting language, even though it can be used to implement one.

"Simply" calling the OS functions sounds like a better idea than it is.

Portability isn't as much of an issue as you imply in this case since the
OS is already specified as DARWIN.

Well, sure. If we're going to assume that *only* Darwin is relevant (and
the #ifdef isn't part of a series of quite similar #ifdefs, which I
would expect) then by all means make it completely Darwin-specific.

The reason many resort to such bletcherous hacks as parsing the output
of ifconfig is that this is *still* more portable and reliable than
trying to use the ioctl-of-the-month of whatever version of whatever
operating system we're compiling for. You'll have to leave POSIX town
for that and enter the system call jungle.

I won't start an off-topic debate on the portability of the ifconfig
command (afaik not standardised by POSIX either)

Correct; the issue is fully one of relative reliability. No standard of
any kind will help you out here.
vs OS/library functions.

I will say that such an approach in general is very unidiomatic C
I'd agree with that.
and the assumption of the availability and format of a non-standard
external command is IMO very dubious not least because of the issues
Walter raised. From the point of view of Standard C, the ifconfig
command could do anything, if it even exists.
Oh, come on now. #ifdef __DARWIN__, remember? We've left standard C way,
way behind here. You're quite right that as far as the *standard* goes,
system() could do anything from getting you details on network addresses
to making a nice hot cup of tea, but we left standard C the minute we
started talking about MAC addresses.

In that respect, using ifconfig (by invoking it with a full path and by
using a proper, non-intrusive way of getting the output) is only
slightly more specific than system calls.
Such an approach is far better suited to a scripting language, and I
second the "bletcherous" description.

When developing a C application that needs to run on multiple systems and
rely on this functionality, and a portable library doesn't exist as you
seem to believe is true in this case, better to enter the jungle for each
system as required. It's worth the extra effort to do the job properly.

Maybe, maybe not, and since I'm not the one doing it, I'll leave it at
that. It's easy to design the perfect solution from here, but things
always look different when you're actually doing them.

S.

[Netocrat]

On Fri, 11 Nov 2005 21:12:22 +0100, Skarmander wrote:

Netocrat wrote: [parsing the output of ifconfig to determine a MAC address]

[T]he assumption of the availability and format of a non-standard
external command is IMO very dubious not least because of the issues
Walter raised. From the point of view of Standard C, the ifconfig
command could do anything, if it even exists.

Oh, come on now. #ifdef __DARWIN__, remember? We've left standard C way,
way behind here.

OK, those comments didn't fit well in context.
In that respect, using ifconfig (by invoking it with a full path and by
using a proper, non-intrusive way of getting the output) is only
slightly more specific than system calls.

You're right - in that case it's only slightly more specific.

Perhaps my view is coloured by once seeing a classmate call popen("ls") or
similar and parse the output when coding a Unix recursive directory
listing C assignment, and not understand why that code was a poor idea.

[...]
--
http://members.dodo.com.au/~netocrat

[Skarmander]

Netocrat wrote:
<snip>

Perhaps my view is coloured by once seeing a classmate call popen("ls") or
similar and parse the output when coding a Unix recursive directory
listing C assignment, and not understand why that code was a poor idea.

It is?

Just kidding, honest. :-) The crucial difference here is that this is
well-supported by POSIX calls, so you'd have to be daft to pick the
other solution.

Besides, it should be system("find -type d"). And if you need the output
formatted differently, you can pipe that through sed...

S.

[Skarmander]

Skarmander wrote:

Netocrat wrote:
<snip>

Perhaps my view is coloured by once seeing a classmate call
popen("ls") or
similar and parse the output when coding a Unix recursive directory
listing C assignment, and not understand why that code was a poor idea.

It is?

Just kidding, honest. :-) The crucial difference here is that this is
well-supported by POSIX calls, so you'd have to be daft to pick the
other solution.

Besides, it should be system("find -type d"). And if you need the output
formatted differently, you can pipe that through sed...

Hmm, I parsed that as "recursive listing of directories", that is,
listing only directories. But if files are to be included as well, it's
even simpler, of course, just use system("find").

S.

[Netocrat]

On Sat, 12 Nov 2005 03:17:01 +0100, Skarmander wrote:

Skarmander wrote:

Netocrat wrote:
<snip>

Perhaps my view is coloured by once seeing a classmate call
popen("ls") or
similar and parse the output when coding a Unix recursive directory
listing C assignment, and not understand why that code was a poor idea.

It is?

Just kidding, honest. :-)
Some people genuinely might not see a problem with it. It works after
all. My main beefs with it are:
* there's no need to fork off a new process
* it's less efficient
* returned data is less well structured or informative
* error reporting is not well integrated or standardised.
The crucial difference here is that this
is well-supported by POSIX calls, so you'd have to be daft to pick the
other solution.
Having a solution at all seemed to be this student's main goal.
Besides, it should be system("find -type d"). And if you need the
output formatted differently, you can pipe that through sed...

Hmm, I parsed that as "recursive listing of directories", that is,
listing only directories. But if files are to be included as well, it's
even simpler, of course, just use system("find").

Files were included. It was slightly complicated by the fact that each
subdirectory was supposed to be printed by a new POSIX thread, precluding
the use of "find" or "ls -R".

IIRC, the approach was something like:
1) popen("ls")
2) for each directory entry in the output ignoring "." and ".."
2.1) print it
2.2) check whether it is a directory by attempting to cd to it
if so:
2.2.1) create a new thread, which starts at (1)
2.2.2) cd back to the parent directory

My main recollection is that commands were preferred to function calls
whereever possible.

--
http://members.dodo.com.au/~netocrat

[Walter Roberson]

In article <pa****************************@dodo.com.au>,
Netocrat <ne******@dodo.com.au> wrote:

Netocrat wrote: Perhaps my view is coloured by once seeing a classmate call
popen("ls") or

Some people genuinely might not see a problem with it. It works after
all. My main beefs with it are:
* there's no need to fork off a new process
* it's less efficient
* returned data is less well structured or informative
* error reporting is not well integrated or standardised.

[still OT]

People used to have mysterious problems with programs suddenly
not being able to find their files.... that were tracked down to
having installed GNU "ls" with its colourization of filenames by type.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson

[SM Ryan]

Not sure who whined to supernews about alt.usenet.kooks
/comp.lang.c crossposts. Just means I use two posts
instead of the more efficient crossposted one.

Skarmander <in*****@dontmailme.com> wrote:
# Netocrat wrote:
# <snip>
# > Perhaps my view is coloured by once seeing a classmate call popen("ls") or
# > similar and parse the output when coding a Unix recursive directory
# > listing C assignment, and not understand why that code was a poor idea.
# >
# It is?
#
# Just kidding, honest. :-) The crucial difference here is that this is
# well-supported by POSIX calls, so you'd have to be daft to pick the
# other solution.
#
# Besides, it should be system("find -type d"). And if you need the output
# formatted differently, you can pipe that through sed...

Interesting. If someone uses POSIX calls, then you whine about
being off-topic. Instead it's done in ANSI C and you have to
whine because you can't whine about being off-topic.

By the way, sunshine, you'd best learn about the #ifdefs used
to bracket system specific code, because you will see that in
real world code.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
No pleasure, no rapture, no exquisite sin greater than central air.

[SM Ryan]

Netocrat <ne******@dodo.com.au> wrote:
# On Sat, 12 Nov 2005 03:17:01 +0100, Skarmander wrote:
# > Skarmander wrote:
# >> Netocrat wrote:
# >> <snip>
# >>
# >>> Perhaps my view is coloured by once seeing a classmate call
# >>> popen("ls") or
# >>> similar and parse the output when coding a Unix recursive directory
# >>> listing C assignment, and not understand why that code was a poor idea.
# >>>
# >> It is?
# >>
# >> Just kidding, honest. :-)
#
# Some people genuinely might not see a problem with it. It works after
# all. My main beefs with it are:

Yeah, a lot of beginners prefer to re-implement what is already done
in the name of efficiency. Much better to spend a week reimplementing
find(1) than five minutes coding a call to it.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I love the smell of commerce in the morning.

[Skarmander]

SM Ryan wrote:

Not sure who whined to supernews about alt.usenet.kooks
/comp.lang.c crossposts. Just means I use two posts
instead of the more efficient crossposted one.

Skarmander <in*****@dontmailme.com> wrote:
# Netocrat wrote:
# <snip>
# > Perhaps my view is coloured by once seeing a classmate call popen("ls") or
# > similar and parse the output when coding a Unix recursive directory
# > listing C assignment, and not understand why that code was a poor idea.
# >
# It is?
#
# Just kidding, honest. :-) The crucial difference here is that this is
# well-supported by POSIX calls, so you'd have to be daft to pick the
# other solution.
#
# Besides, it should be system("find -type d"). And if you need the output
# formatted differently, you can pipe that through sed...

Interesting. If someone uses POSIX calls, then you whine about
being off-topic. Instead it's done in ANSI C and you have to
whine because you can't whine about being off-topic.

By the way, sunshine, you'd best learn about the #ifdefs used
to bracket system specific code, because you will see that in
real world code.

It is utterly unclear to me who you're replying to, but it seems to be
some personification of the newsgroup itself. Traditionally, replies
address the person who last posted, but I have a hard time reconciling
anything you say with anything I did.

S.

[Netocrat]

On Sat, 12 Nov 2005 07:56:56 +0000, SM Ryan wrote:

Netocrat <ne******@dodo.com.au> wrote:
# On Sat, 12 Nov 2005 03:17:01 +0100, Skarmander wrote:
# > Skarmander wrote:
# >> Netocrat wrote:
# >> <snip>
# >>
# >>> Perhaps my view is coloured by once seeing a classmate call
# >>> popen("ls") or
# >>> similar and parse the output when coding a Unix recursive directory
# >>> listing C assignment, and not understand why that code was a poor idea.
# >>>
# >> It is?
# >>
# >> Just kidding, honest. :-)
#
# Some people genuinely might not see a problem with it. It works after
# all. My main beefs with it are:

Yeah, a lot of beginners prefer to re-implement what is already done
in the name of efficiency. Much better to spend a week reimplementing
find(1) than five minutes coding a call to it.

In this case "find" wasn't a solution (see snipped explanation of
threading requirements) and the solution used didn't avoid much code or
effort, if any - there was a parallel approach using POSIX function calls.

In effect this was a limited implementation of "find" for learning
purposes - and implementing "find" in C using calls to "ls" is a poor idea.

--
http://members.dodo.com.au/~netocrat

[Chris Torek]

In article <11*************@corp.supernews.com>
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

Must be hard to have a leaky killfile.

(I am not sure to whom this was addressed, as it was in a followup
to me, but Mr Ryan has never been in my comp.lang.c kill-file. I
prefer not list its members, although I will mention that there are
11 numerically, counting multiple addresses as a single identity,
and ignoring killed subject lines.)

In article <11*************@corp.supernews.com>
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
... You can do something like
#ifdef __DARWIN__
system("ifconfig >config.txt");
FILE *f = fopen("config.txt","rt");
...read and parse the file f...
fclose(f);
#endif

(Of course, if one wishes to be so system-specific, popen() with
ifconfig piped to an appropriate sed command, or similar, would
probably be better.)
In article <dl**********@canopus.cc.umanitoba.ca>
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> raises the possibility of a problem with $PATH (which does
exist but is not, I think, the heart of the matter).

In article <dl*********@news1.newsguy.com> I wrote: Even worse, suppose it actually works. What is "the" MAC address
on my machine here?

How would a library interface avoid this issue any better than
a command line?

Indeed, it would not. But that is my point, which perhaps I did
not express appropriately clearly: the entire approach, of finding
"the" MAC-address of a given machine, is a poor one. Of course,
Bob Metcalf (who designed the original Ethernet at Xerox PARC) and
company intended all along that the six-byte address be unique to
a given machine: no matter how many Ethernet adapters a machine
had (from zero to infinity) it would have had a single six-byte
Media Access Control address. But this is not how things played
out; today, machines generally have one MAC-address per interface.
Machines with no interfaces will have no MAC-address, while those
with many will have many. Machines with one interface are common,
but if the interface breaks or is replaced with a new, faster
interface, the MAC-address changes (usually -- there are a few
exceptions).

It is thus unwise to attempt to use any MAC-address(es) of any
given machine for any purpose other than that implemented in the
network layer already -- and if one is writing said network layer,
the method(s) for obtaining it will generally be specific to the
interface card(s), so no single method description suffices. In
my experience, those asking the question are almost always attempting
to produce "node-locked" (licensed) software, and are using a method
that is bound to cause them more grief than they expect. The answer
to "how do I do this" usually winds up being: "the best way is not
to do it at all."

(I have also found that, for those who are already set on a particular
course, the best way to get them to reconsider this is to ask them
to solve one of the less-immediately-obvious problems involved --
in this case, to define "the" MAC-address for my machine with three
Ethernet adapters. This does not always work, of course: sometimes
they dismiss the problem off-hand, or propose a simplistic solution
like taking the "first one". Of course the "first one" changes
from time to time....)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[James McIninch]

Computers don't have MAC addresses, network cards do.
You also need to specify if you want the default MAC address or the current
one (if set to something else).

It's not terribly pertinent since C itself has no way to obtain the
information. You'll want to use third-party software for that.

chellappa wrote:

hi all
I need to write a program to find mac address of a my computer using
libaries, is
this possible? How?
thanks

--
Remove '.nospam' from e-mail address to reply by e-mail

[Mark McIntyre]

On 13 Nov 2005 04:55:17 GMT, in comp.lang.c , Chris Torek
<no****@torek.net> wrote:

(I have also found that, for those who are already set on a particular
course, the best way to get them to reconsider this is to ask them
to solve one of the less-immediately-obvious problems involved --
in this case, to define "the" MAC-address for my machine with three
Ethernet adapters.
Personally I don't consider this a less immediately obvious problem -
most of our database and fileservers have at least three NICs, a
primary, a failover and a dedicated one for the backup service. Some
have a couple more for eg dedicated mirroring to our DR site.
like taking the "first one". Of course the "first one" changes
from time to time....)

like f'rinstance any time you have a hardware issue or contingency
event. With several thousand servers, getting one or two of those a
/day/ isn't too unexpected.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----