Source code of common Unix command: where can you find it ?
Spendius
I'd like to know where I could find, if possible, the C code to
the Unix commands (like 'ls', 'strings', 'cat', 'grep'...). Is it
available somewhere ?? I already tried to find it from different
search engines, but never successed.
Thanks for any help !
Regards,
Spendius
Arnold Hendriks
> I'd like to know where I could find, if possible, the C code to
> the Unix commands (like 'ls', 'strings', 'cat', 'grep'...). Is it
> available somewhere ?? I already tried to find it from different
> search engines, but never successed.
or *BSD systems.
Eg, if you look for ls, you could try the source code package
for Linux' fileutils. Most distributions come with source code,
and it can be found all over the web.
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
Nils O. Selåsdal
> Hi,
> I'd like to know where I could find, if possible, the C code to
> the Unix commands (like 'ls', 'strings', 'cat', 'grep'...). Is it
> available somewhere ?? I already tried to find it from different
> search engines, but never successed.
Or, go to www.gnu.org/software/ the 'ls' command are e.g. found
in the fileutils package.
Floyd Davidson
>In comp.unix.programmer Spendius <spen...@mailandnews.com> wrote:
>> I'd like to know where I could find, if possible, the C code to
>> the Unix commands (like 'ls', 'strings', 'cat', 'grep'...). Is it
>> available somewhere ?? I already tried to find it from different
>> search engines, but never successed.
>For example, you could download source packages for the Linux
>or *BSD systems.
>
>Eg, if you look for ls, you could try the source code package
>for Linux' fileutils. Most distributions come with source code,
>and it can be found all over the web.
Lets give credit where credit is due. Linux is a wonderful
kernel, but it has no filutils package or any other utilities
that are common to all UNIXen.
The Free Software Foundation's GNU project does have a fileutils
package, and virtually every Linux distribution does use it, as
do many other UNIX or UNIX-like systems.
GNU software can be found at www.gnu.org or ftp.gnu.org
--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Nils O. Selåsdal
code for the ls command used in e.g. linux can be found at....
BSD Bob the old greybeard BSD freak
For as close to the real thing as you can get, get an antique unix
source code license from SCO (Caldera?) and visit the PUPS archives
in Australia. All the available unix source code from V1 through
the BSD's, but not including SysV is there. But, for a good generic
approximation thereto, as other have said, visit the freebie unix
sites, particularly the BSD sites since they will be a bit closer
to the real thing, by lineage, than Linux and gnu will. Start with
The Unix Heritage Society (TUHS) at http://minnie.tuhs.org/TUHS/.
For what you are looking to find, I would probably start with the
V7 or 32V trees or maybe the 4.3BSD tree.
Bob
Mike Castle
Spendius <spen...@MailAndNews.com> wrote:
>Hi,
>I'd like to know where I could find, if possible, the C code to
>the Unix commands (like 'ls', 'strings', 'cat', 'grep'...). Is it
>available somewhere ?? I already tried to find it from different
>search engines, but never successed.
While many have suggested the gnu utilities, there are other sources as
well.
busybox, for instance, is an interested implementation of many utilities,
in a stripped down, basic format.
If you're interested in studying the utilities, that might be a better
starting point than the GNU infrastructure.
Another thing to point out is that many of the utilities listed above are
in separate packages. ls is in fileutils. strings is in binutils (yes, it
falls into the same category as ld, nm, as, ar). cat is in textutils.
grep is in grep. find and xargs is in findutils. And so on.
And definitly the various *BSD implementations would be good references as
well. It never hurts to look at a variety of implementations of something
to get different ideas on how to solve problems.
mrc
--
Mike Castle dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
those who know me have no need of my name
>Lets give credit where credit is due. Linux is a wonderful
>kernel, but it has no filutils package or any other utilities
>that are common to all UNIXen.
that's because: a) it's not a unix and b) it's a kernel. so i agree, but
without the slur.
>The Free Software Foundation's GNU project does have a fileutils
>package, virtually every Linux distribution does use it,
yep. and it's generally very good. (there are some aspects of the gnu
utilities that are a pita, and against the *nix grain, but that's somewhat
to be expected, and not usually too horrible.)
>as do many other UNIX or UNIX-like systems.
would you mind naming some? certainly not hp, ibm, or sun. nor any of the
*bsd projects.
note: i am not asking what systems the gnu fileutils can be built upon, but
which companies supply or use it as the basis of the utilities they
distribute.
--
okay, have a sig then
Floyd Davidson
><87r8t2c...@barrow.com> divulged:
Your concept of attributes is strange! That is the message-ID, not
an email address. I guess it has more significance to you, given
that you also hide your own name and email address...
>>Lets give credit where credit is due. Linux is a wonderful
>>kernel, but it has no filutils package or any other utilities
>>that are common to all UNIXen.
>
>that's because: a) it's not a unix and b) it's a kernel. so i agree, but
>without the slur.
Linux is a unix OS. But what slur do you see there? Linux is
the kernel, and the utils for every Linux distribution I know of
are from GNU.
>>The Free Software Foundation's GNU project does have a fileutils
>>package, virtually every Linux distribution does use it,
>
>yep. and it's generally very good. (there are some aspects of the gnu
>utilities that are a pita, and against the *nix grain, but that's somewhat
>to be expected, and not usually too horrible.)
With out specifics I'm not sure what you are referring to. I
can't offhand think of any of the utils that go against the
"*nix grain".
>>as do many other UNIX or UNIX-like systems.
>
>would you mind naming some? certainly not hp, ibm, or sun. nor any of the
>*bsd projects.
GNU utils will work on every single one of those.
>note: i am not asking what systems the gnu fileutils can be built upon, but
>which companies supply or use it as the basis of the utilities they
>distribute.
I'm not saying that it is the default or distribution set of
utilities. I'm saying they work on virtually all UNIX systems.
The nice part is they are in many cases better than the
defaults, too. Which is part of why the FSF should get credit
where due for the GNU project.
those who know me have no need of my name
<87n13ok...@barrow.com> divulged:
>those who know me have no need of my name <not-a-rea...@usa.net> wrote:
>><87r8t2c...@barrow.com> divulged:
>Your concept of attributes is strange! That is the message-ID, not
>an email address.
indeed it is the message-id of the article that contained the text which i
quoted. how is this not an attribution?
>I guess it has more significance to you, given that you also hide your own
>name and email address...
ah, another slur and a baseless assumption.
of course message-id's are significant to me. as are people's names and
e-mail addresses, the day and date they wrote something, etc, etc, etc.;
but, i choose to use a terse description of the source of what i quoted, so
that even those stuck with a horrid interface (e.g., googlegroups) that
would like to have read your article in full but do not have access to all
headers would have the most significant item that leads directly to the
source material.
>>>Lets give credit where credit is due. Linux is a wonderful
>>>kernel, but it has no filutils package or any other utilities
>>>that are common to all UNIXen.
>>
>>that's because: a) it's not a unix and b) it's a kernel. so i agree, but
>>without the slur.
>
>Linux is a unix OS.
no, it's a kernel, and some device drivers. and it's not even a unix
kernel, it's much closer to bsd or posix, though it's really a mash of all
of those along with other stuff.
>But what slur do you see there?
since linux is just a kernel there is no reason to say "but" as if not
having a "fileutil package" or "any other utilities" is some sort of lack.
>Linux is the kernel, and the utils for every Linux distribution I know of
>are from GNU.
"the utils" is a little weakly bound, i don't know whether you are
referring only to those utilities present in the gnu fileutils or all the
utilities "that are common to all unixen." so i'll respond to both
possibilities:
on the first hand: okay, every distribution of which you are aware uses the
gnu fileutils. however it is obvious that you are unaware of several
distributions which use a linux kernel but which do not use the gnu
fileutils.
on the second hand: there are many, non-trivial utilities which are not
supplied by the gnu project even in the most common and well known
distributions.
>>>The Free Software Foundation's GNU project does have a fileutils
>>>package, virtually every Linux distribution does use it,
>>
>>yep. and it's generally very good. (there are some aspects of the gnu
>>utilities that are a pita, and against the *nix grain, but that's somewhat
>>to be expected, and not usually too horrible.)
>
>With out specifics I'm not sure what you are referring to. I
>can't offhand think of any of the utils that go against the
>"*nix grain".
the *nix grain is to have terse commands and options, not horribly long
ones, e.g., until the tidal wave patch to gnu tar that made "I" the option
to cause bzip2 to be the compressor the gnu tar project wanted folks to use
`--use-compress-program=bzip2,' for which there is no shorter option. (i
would have been happier if "I" were the short option for designating a
compression program, e.g., `-Ibzip2.')
further they (the gnu project) often get "full of themselves," deciding to
abandon prior practice because they deem it not worthy, e.g., gnu tar
builds archives that by default, in the proper circumstances, cannot be
untar'd by non-gnu tar programs. it is their right to design their tools
as they see fit, and it's mine to be peeved by it when it (tries to) bite
me.
>>>as do many other UNIX or UNIX-like systems.
>>
>>would you mind naming some? certainly not hp, ibm, or sun. nor any of the
>>*bsd projects.
>
>GNU utils will work on every single one of those.
i knew you'd go there.
Stan Brown
add...@usa.net> wrote in comp.unix.programmer:
>indeed it is the message-id of the article that contained the text which i
>quoted. how is this not an attribution?
It is customary to attribute articles to their authors, not to the
(mechanically generated and essentially meaningless) Message-ID.
Particularly when there are multiple exchanges in a thread,
attributing to authors makes it very much clearer who holds which
position.
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://oakroadsystems.com
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
those who know me have no need of my name
>those who know me have no need of my name <not-a-real-
>add...@usa.net> wrote in comp.unix.programmer:
>>indeed it is the message-id of the article that contained the text which i
>>quoted. how is this not an attribution?
>
>It is customary to attribute articles to their authors, not to the
>(mechanically generated and essentially meaningless) Message-ID.
it's also customary to respect a followup-to. think about that, and what
you did, and what i do. indeed even attribution lines such as you use
aren't always all that one might want, e.g., yours only mentions c.u.p yet
that is not the only group in which these posts are available.