Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.debian > #7418 > unrolled thread

mc finds more than `find` finds?

Back to article view | Back to alt.os.linux.debian

Contents

  mc finds more than `find` finds? WhoCares@gmail.com - 2015-11-28 00:37 +0000
    Re: mc finds more than `find` finds? William Unruh <unruh@invalid.ca> - 2015-11-28 00:52 +0000
      Re: mc finds more than `find` finds? Arkadiusz Drabczyk <arkadiusz@domain.invalid> - 2015-11-28 16:15 +0000
        Re: mc finds more than `find` finds? William Unruh <unruh@invalid.ca> - 2015-11-28 17:59 +0000
          Re: mc finds more than `find` finds? Teemu Likonen <tlikonen@iki.fi> - 2015-11-28 20:07 +0200
            Re: mc finds more than `find` finds? William Unruh <unruh@invalid.ca> - 2015-11-28 20:44 +0000
              Re: mc finds more than `find` finds? Teemu Likonen <tlikonen@iki.fi> - 2015-11-29 12:41 +0200
          Re: mc finds more than `find` finds? Arkadiusz Drabczyk <arkadiusz@domain.invalid> - 2015-11-28 18:14 +0000
            Re: mc finds more than `find` finds? floyd@apaflo.com (Floyd L. Davidson) - 2015-11-28 11:52 -0900
              Re: mc finds more than `find` finds? Martijn Dekker <martijn@inlv.demon.nl> - 2015-11-29 16:35 +0100
                Re: mc finds more than `find` finds? floyd@apaflo.com (Floyd L. Davidson) - 2015-11-29 10:49 -0900
                  Re: mc finds more than `find` finds? Richard Kettlewell <rjk@greenend.org.uk> - 2015-11-29 20:24 +0000
                    Re: mc finds more than `find` finds? floyd@apaflo.com (Floyd L. Davidson) - 2015-11-29 14:09 -0900
                      Re: mc finds more than `find` finds? Richard Kettlewell <rjk@greenend.org.uk> - 2015-11-30 09:24 +0000
                        Re: mc finds more than `find` finds? Eef Hartman <E.J.M.Hartman@gmail.com> - 2015-11-30 10:08 +0000
                Re: mc finds more than `find` finds? William Unruh <unruh@invalid.ca> - 2015-11-29 20:07 +0000
                Re: mc finds more than `find` finds? Eef Hartman <E.J.M.Hartman@gmail.com> - 2015-11-29 20:10 +0000
              Re: mc finds more than `find` finds? no.top.post@gmail.com - 2016-01-04 23:07 +0000
                Re: mc finds more than `find` finds? The Natural Philosopher <tnp@invalid.invalid> - 2016-01-04 23:27 +0000
                  Re: mc finds more than `find` finds? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-01-04 19:28 -0500
                Re: mc finds more than `find` finds? Jerry Peters <jerry@example.invalid> - 2016-01-05 21:05 +0000
    Re: mc finds more than `find` finds? marrgol <marrgol@address.invalid> - 2015-11-28 02:22 +0100
    Re: mc finds more than `find` finds? Joe Beanfish <joebeanfish@nospam.duh> - 2015-11-30 15:59 +0000
      Re: mc finds more than `find` finds? Unknown <dog@gmail.com> - 2016-01-03 12:52 +0000

Page 1 of 2  [1] 2  Next page →

#7418 — mc finds more than `find` finds?

I'm still searching for a way to know the pid of eg. the instance of
`wily` which is has a certain file open.

`pgrep wily` lists all the instances of 'wily'

I was hoping that, I'd find which wily has opened file *CONTROL* by:-
for PID in `pgrep wily`; do find /proc/$PID -exec grep -l "CONTROL" {} \;  >> trace; done
--- that's supposed to be ONE line ---

Using successive refinement:
 first I used mc to browse /proc/24357 to find a suitable search target.
Obviously "wily" would be there.

 Then I 'confirmed ?': 
find /proc/24357 -exec grep  "wily" {} \;
 but that failed, although mc could find several "wily" in /proc/24357

OK, we know that /proc is some kind of spooky FS ?
So, I copied to /find, [using mc] 2 of the files of /proc/24357 which
contain "wily", and of course, they are found by:
  find /find -exec grep  "wily" {} \; ==
./status 
./environ

How can mc look into /proc/24357 and show the contents if the basic
`find` can't see it?

[toc] | [next] | [standalone]

#7419

On 2015-11-28, WhoCares@gmail.com <WhoCares@gmail.com> wrote:
> I'm still searching for a way to know the pid of eg. the instance of
> `wily` which is has a certain file open.
>
> `pgrep wily` lists all the instances of 'wily'
>
> I was hoping that, I'd find which wily has opened file *CONTROL* by:-
> for PID in `pgrep wily`; do find /proc/$PID -exec grep -l "CONTROL" {} \;  >> trace; done
> --- that's supposed to be ONE line ---
>
> Using successive refinement:
>  first I used mc to browse /proc/24357 to find a suitable search target.
> Obviously "wily" would be there.
>
>  Then I 'confirmed ?': 
> find /proc/24357 -exec grep  "wily" {} \;

You need to escape {}  (ie \{\}, or '{}' or the shell will interpret it. 


>  but that failed, although mc could find several "wily" in /proc/24357

egrep -r would work better than your "find" line
Also, while you might find the command line arguments, if wiley opened
the file, I do not think you would find it this way. 
>
> OK, we know that /proc is some kind of spooky FS ?
> So, I copied to /find, [using mc] 2 of the files of /proc/24357 which
> contain "wily", and of course, they are found by:
>   find /find -exec grep  "wily" {} \; ==
> ./status 
> ./environ
>
> How can mc look into /proc/24357 and show the contents if the basic
> `find` can't see it?

grep -r "wily" /proc/24357

>
>
>
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#7422

On 2015-11-28, William Unruh <unruh@invalid.ca> wrote:
> On 2015-11-28, WhoCares@gmail.com <WhoCares@gmail.com> wrote:
>> I'm still searching for a way to know the pid of eg. the instance of
>> `wily` which is has a certain file open.
>>
>> `pgrep wily` lists all the instances of 'wily'
>>
>> I was hoping that, I'd find which wily has opened file *CONTROL* by:-
>> for PID in `pgrep wily`; do find /proc/$PID -exec grep -l "CONTROL" {} \;  >> trace; done
>> --- that's supposed to be ONE line ---
>>
>> Using successive refinement:
>>  first I used mc to browse /proc/24357 to find a suitable search target.
>> Obviously "wily" would be there.
>>
>>  Then I 'confirmed ?': 
>> find /proc/24357 -exec grep  "wily" {} \;
>
> You need to escape {}  (ie \{\}, or '{}' or the shell will interpret it. 

Which shell interprets `{}'?  I have never seen one.

>>  but that failed, although mc could find several "wily" in /proc/24357
>
> egrep -r would work better than your "find" line

`egrep' is deprecated.  From
http://pubs.opengroup.org/onlinepubs/009604499/utilities/grep.html:

"This grep has been enhanced in an upwards-compatible way to provide
the exact functionality of the historical egrep and fgrep commands as
well. It was the clear intention of the standard developers to
consolidate the three greps into a single command."

From `man grep' of GNU grep:

"In addition, the variant programs egrep and fgrep are the same as
grep -E and grep -F, respectively.  These variants are deprecated, but
are provided for backward compatibility."

-- 
Arkadiusz Drabczyk

[toc] | [prev] | [next] | [standalone]

#7423

On 2015-11-28, Arkadiusz Drabczyk <arkadiusz@domain.invalid> wrote:
> On 2015-11-28, William Unruh <unruh@invalid.ca> wrote:
>> On 2015-11-28, WhoCares@gmail.com <WhoCares@gmail.com> wrote:
>>> I'm still searching for a way to know the pid of eg. the instance of
>>> `wily` which is has a certain file open.
>>>
>>> `pgrep wily` lists all the instances of 'wily'
>>>
>>> I was hoping that, I'd find which wily has opened file *CONTROL* by:-
>>> for PID in `pgrep wily`; do find /proc/$PID -exec grep -l "CONTROL" {} \;  >> trace; done
>>> --- that's supposed to be ONE line ---
>>>
>>> Using successive refinement:
>>>  first I used mc to browse /proc/24357 to find a suitable search target.
>>> Obviously "wily" would be there.
>>>
>>>  Then I 'confirmed ?': 
>>> find /proc/24357 -exec grep  "wily" {} \;
>>
>> You need to escape {}  (ie \{\}, or '{}' or the shell will interpret it. 
>
> Which shell interprets `{}'?  I have never seen one.

Have you tried it?


>
>>>  but that failed, although mc could find several "wily" in /proc/24357
>>
>> egrep -r would work better than your "find" line
>
> `egrep' is deprecated.  From
> http://pubs.opengroup.org/onlinepubs/009604499/utilities/grep.html:

So, then use grep. Sheesh. 
Did you think that the purpose of my suggestion was to push egrep?

[toc] | [prev] | [next] | [standalone]

#7424

[Multipart message — attachments visible in raw view] — view raw

William Unruh [2015-11-28 17:59:54Z] wrote:

> On 2015-11-28, Arkadiusz Drabczyk <arkadiusz@domain.invalid> wrote:
>> Which shell interprets `{}'? I have never seen one.
>
> Have you tried it?

I'll start:

    $ /bin/bash -c 'echo {}'
    {}
    $ /bin/sh -c 'echo {}'
    {}

[toc] | [prev] | [next] | [standalone]

#7426

On 2015-11-28, Teemu Likonen <tlikonen@iki.fi> wrote:
> --=-=-=
> Content-Type: text/plain
>
> William Unruh [2015-11-28 17:59:54Z] wrote:
>
>> On 2015-11-28, Arkadiusz Drabczyk <arkadiusz@domain.invalid> wrote:
>>> Which shell interprets `{}'? I have never seen one.
>>
>> Have you tried it?
>
> I'll start:
>
>     $ /bin/bash -c 'echo {}'
>     {}
>     $ /bin/sh -c 'echo {}'
>     {}

Forget it. That was not what I suggested you try, but it is pointless to
talk with you. 

[toc] | [prev] | [next] | [standalone]

#7428

[Multipart message — attachments visible in raw view] — view raw

William Unruh [2015-11-28 20:44:39Z] wrote:

> On 2015-11-28, Teemu Likonen <tlikonen@iki.fi> wrote:
>> William Unruh [2015-11-28 17:59:54Z] wrote:
>>> On 2015-11-28, Arkadiusz Drabczyk <arkadiusz@domain.invalid> wrote:
>>>> Which shell interprets `{}'? I have never seen one.
>>> Have you tried it?
>> I'll start:
>>
>>     $ /bin/bash -c 'echo {}'
>>     {}
>>     $ /bin/sh -c 'echo {}'
>>     {}
>
> Forget it. That was not what I suggested you try, but it is pointless
> to talk with you.

The point came from this:

    William Unruh [2015-11-28 00:52:45Z] wrote:
    > You need to escape {} (ie \{\}, or '{}' or the shell will
    > interpret it.

Yes. Shell interprets it but there's not much need for escaping {}
because the result is still {}. Or what is the need? Probably you just
forgot that plain {} doesn't need escaping, even though { and } have
special meaning sometimes. That's fine and not a problem here. I forget
shell's special characters sometimes.

[toc] | [prev] | [next] | [standalone]

#7425

On 2015-11-28, William Unruh <unruh@invalid.ca> wrote:
>>> You need to escape {}  (ie \{\}, or '{}' or the shell will interpret it. 
>>
>> Which shell interprets `{}'?  I have never seen one.
>
> Have you tried it?

Yes. I tried this:

$ echo {}

on bash, ash, mksh, zsh and csh.  I have never seen anyone escaping
`{}'.  It's not the same as `(' and `)'.  I know that `man find' says
that it might be necessary to quote `{}' but I have never come across
a shell where it's necessary.

>>> egrep -r would work better than your "find" line
>>
>> `egrep' is deprecated.  From
>> http://pubs.opengroup.org/onlinepubs/009604499/utilities/grep.html:
>
> So, then use grep. Sheesh. 
> Did you think that the purpose of my suggestion was to push egrep?

I don't know what was your purpose but I think it's just worth
mentioning.  In the long run egrep may be no longer available on some
systems.  It's just a note, not a correction of your answer.

-- 
Arkadiusz Drabczyk

[toc] | [prev] | [next] | [standalone]

#7427

Arkadiusz Drabczyk <arkadiusz@domain.invalid> wrote:
>On 2015-11-28, William Unruh <unruh@invalid.ca> wrote:
>>>> You need to escape {}  (ie \{\}, or '{}' or the shell will interpret it.
>>>
>>> Which shell interprets `{}'?  I have never seen one.
>>
>> Have you tried it?
>
>Yes. I tried this:
>
>$ echo {}

Both opening and closing braces are reserved words.  Shell interpretation
is context sensitive, but the above echo command actually did in fact
interpret (and reject as meaningful) the context.  Try this:

 $ echo "Now "{'is','is not'}" the time."

Or something simple,

 $ echo a{b,c,d}e

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#7429

In article <87y4dh7sol.fld@barrow.com>,
 floyd@apaflo.com (Floyd L. Davidson) wrote:

> Both opening and closing braces are reserved words.

Yes, '{' and '}' are reserved words, but '{}' is not a reserved word. 
(Something can only be a "word" if it's separated by blanks.)

In any case the concept of a reserved word doesn't apply to command 
arguments, so it's moot.

> Try this:
> 
>  $ echo "Now "{'is','is not'}" the time."
> 
> Or something simple,
> 
>  $ echo a{b,c,d}e

This is brace expansion, which is a non-standard[*] extension to 
globbing. It's completely distinct from the reserved words '{' and '}' 
which are for delimiting code blocks.

[*] Brace expansion is supported by bash, *ksh and zsh but not by 
standard sh implementations such as dash or yash.

- M.

[toc] | [prev] | [next] | [standalone]

#7430

Martijn Dekker <martijn@inlv.demon.nl> wrote:
>In article <87y4dh7sol.fld@barrow.com>,
> floyd@apaflo.com (Floyd L. Davidson) wrote:
>
>> Both opening and closing braces are reserved words.
>
>Yes, '{' and '}' are reserved words, but '{}' is not a reserved word.
>(Something can only be a "word" if it's separated by blanks.)
>
>In any case the concept of a reserved word doesn't apply to command
>arguments, so it's moot.

You have removed and then changed the context to which
my statement applied.

The point is still very simple: braces are reserved
words.  They do get "interpreted", and the statement I
replied to incorrectly said they don't.

Your definition of "word" is parochial, and does not
necessarily apply to use of that term in a shell.  From
the bash man page:

 word   A sequence of characters considered as a single unit
        by the shell.  Also known as a token.

Clearly '{}' is a pair of tokens to the parsing engine.
In some contexts they each cause a "word break", and in
other contexts they do not.  When used to delimit a list
they do not cause a break and must be surrounded by
spaces.  When interpreted for expansion there is no need
for a space.

>> Try this:
>>
>>  $ echo "Now "{'is','is not'}" the time."
>>
>> Or something simple,
>>
>>  $ echo a{b,c,d}e
>
>This is brace expansion, which is a non-standard[*] extension to
>globbing. It's completely distinct from the reserved words '{' and '}'
>which are for delimiting code blocks.

Brace expansion has not been standardized, but it is in
almost all major shells.  It needs to be understood by
a shell programmer.

>[*] Brace expansion is supported by bash, *ksh and zsh but not by
>standard sh implementations such as dash or yash.
>
>- M.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#7433

floyd@apaflo.com (Floyd L. Davidson) writes:
> Martijn Dekker <martijn@inlv.demon.nl> wrote:
>> floyd@apaflo.com (Floyd L. Davidson) wrote:
>>
>>> Both opening and closing braces are reserved words.
>>
>>Yes, '{' and '}' are reserved words, but '{}' is not a reserved word.
>>(Something can only be a "word" if it's separated by blanks.)
>>
>>In any case the concept of a reserved word doesn't apply to command
>>arguments, so it's moot.
>
> You have removed and then changed the context to which
> my statement applied.
>
> The point is still very simple: braces are reserved
> words.  They do get "interpreted", and the statement I
> replied to incorrectly said they don't.
>
> Your definition of "word" is parochial, and does not
> necessarily apply to use of that term in a shell.  From
> the bash man page:
>
>  word   A sequence of characters considered as a single unit
>         by the shell.  Also known as a token.
>
> Clearly '{}' is a pair of tokens to the parsing engine.
> In some contexts they each cause a "word break", and in
> other contexts they do not.  When used to delimit a list
> they do not cause a break and must be surrounded by
> spaces.  When interpreted for expansion there is no need
> for a space.

‘Interpreted’ was surely the wrong word to use.  Everything’s
interpreted as something; the question is what it is interpreted as, and
what actually matters here is whether the interpretation of ‘{}’ is a
non-literal one.

‘Word’ is a specific category in the definition of the shell command
language, defined via the token recognition rules.  ‘{’ and ‘}’ have no
special interpretation here except as part of ‘${’; they certainly don’t
cause a “word break”.

‘Reserved word’ is a also a specific category, defined shortly after the
token recognition rules.  It’s a small category and ‘{}’ is not in it.

The other possibility, in shells that support it, is brace expansion,
something that happens later than and separately from tokenization.  But
(at least in the case of Bash) that also does not produce a non-literal
interpretation, since ‘{}’ is not a correctly-formed brace expansion.

TLDR: no, you don’t need to quote ‘{}’.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#7434

Richard Kettlewell <rjk@greenend.org.uk> wrote:
>TLDR: no, you donâEUR(Tm)t need to quote âEUR~{}âEUR(Tm).

       find . -type f -exec file '{}' \;

       Runs `file' on every file in or below the current
       directory.  Notice that the braces are enclosed
       in single quote marks to protect them from
       interpretation as shell script punctuation.
       The semicolon is similarly protected by the use
       of a backslash, though single quotes could have
       been used in that case also.


From the man page for find.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#7435

floyd@apaflo.com (Floyd L. Davidson) writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>TLDR: no, you don’t need to quote ‘{}’.
>
>        find . -type f -exec file '{}' \;
>
>        Runs `file' on every file in or below the current
>        directory.  Notice that the braces are enclosed
>        in single quote marks to protect them from
>        interpretation as shell script punctuation.
>        The semicolon is similarly protected by the use
>        of a backslash, though single quotes could have
>        been used in that case also.
>
> From the man page for find.

What’s that supposed to prove?

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#7436

In alt.os.linux.slackware Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>        find . -type f -exec file '{}' \;
>>
>>        Runs `file' on every file in or below the current
>>        directory.  Notice that the braces are enclosed
>>        in single quote marks to protect them from
>>        interpretation as shell script punctuation.
>>        The semicolon is similarly protected by the use
>>        of a backslash, though single quotes could have
>>        been used in that case also.
>>
>> From the man page for find.
> 
> What?s that supposed to prove?

Fom the man page of tcsh:
> As a special case the words `{', `}' and `{}' are passed undisturbed.

So when used as a word (like in the find syntax), {} is "passed
undisturbed and does NOT need to be quoted.

[toc] | [prev] | [next] | [standalone]

#7431

On 2015-11-29, Martijn Dekker <martijn@inlv.demon.nl> wrote:
> In article <87y4dh7sol.fld@barrow.com>,
>  floyd@apaflo.com (Floyd L. Davidson) wrote:
>
>> Both opening and closing braces are reserved words.
>
> Yes, '{' and '}' are reserved words, but '{}' is not a reserved word. 
> (Something can only be a "word" if it's separated by blanks.)
>
> In any case the concept of a reserved word doesn't apply to command 
> arguments, so it's moot.

Of course it does. The shell interprets everything before the command
ever sees it.  If you put it into '' then the shell would not see it. 

Anyway, the OP was wondering why his command did not work. Why do you
not come up with an explanation?
This discussion is going way offtrack. 

[toc] | [prev] | [next] | [standalone]

#7432

In alt.os.linux.slackware Martijn Dekker <martijn@inlv.demon.nl> wrote:
> [*] Brace expansion is supported by bash, *ksh and zsh

AND by tcsh too, I don't know about the standard C-shell, have no
system to test that on.

[toc] | [prev] | [next] | [standalone]

#7699

In article <87y4dh7sol.fld@barrow.com>, floyd@apaflo.com (Floyd L. Davidson) wrote: 

> Arkadiusz Drabczyk <arkadiusz@domain.invalid> wrote:
> >On 2015-11-28, William Unruh <unruh@invalid.ca> wrote:
> >>>> You need to escape {}  (ie \{\}, or '{}' or the shell will interpret it.
> >>>
> >>> Which shell interprets `{}'?  I have never seen one.
> >>
> >> Have you tried it?
> >
> >Yes. I tried this:
> >
> >$ echo {}
> 
> Both opening and closing braces are reserved words.  Shell interpretation
> is context sensitive, but the above echo command actually did in fact
> interpret (and reject as meaningful) the context.  Try this:
> 
>  $ echo "Now "{'is','is not'}" the time."
> 
> Or something simple,
> 
>  $ echo a{b,c,d}e
> 
> -- 
*nix is not science. It's absurd poetry.
"interpret (and reject as meaningful) the context"

That's why *unix users say "try this..try that, it works for me,
I don't know why, but get lucky, be happy";
instead of "it is A...it is B".

[toc] | [prev] | [next] | [standalone]

#7701

On 04/01/16 23:07, no.top.post@gmail.com wrote:
> In article <87y4dh7sol.fld@barrow.com>, floyd@apaflo.com (Floyd L. Davidson) wrote:
>
>> Arkadiusz Drabczyk <arkadiusz@domain.invalid> wrote:
>>> On 2015-11-28, William Unruh <unruh@invalid.ca> wrote:
>>>>>> You need to escape {}  (ie \{\}, or '{}' or the shell will interpret it.
>>>>>
>>>>> Which shell interprets `{}'?  I have never seen one.
>>>>
>>>> Have you tried it?
>>>
>>> Yes. I tried this:
>>>
>>> $ echo {}
>>
>> Both opening and closing braces are reserved words.  Shell interpretation
>> is context sensitive, but the above echo command actually did in fact
>> interpret (and reject as meaningful) the context.  Try this:
>>
>>   $ echo "Now "{'is','is not'}" the time."
>>
>> Or something simple,
>>
>>   $ echo a{b,c,d}e
>>
>> --
> *nix is not science. It's absurd poetry.
> "interpret (and reject as meaningful) the context"
>
> That's why *unix users say "try this..try that, it works for me,
> I don't know why, but get lucky, be happy";
> instead of "it is A...it is B".
>
You sound like the twats that invented PASCAL, They didnt want any 
inconsistencies, so they wrote an academically perfect language.

And then realised that an academically perfect language cant have any IO....


C and UNIX were developed extremely fast by a couple of dedicated engineers.

Both have stood the test of time.  That says something.

UNIX and C are older than Windows, that's fer sure.


-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's 
too dark to read.

Groucho Marx

[toc] | [prev] | [next] | [standalone]

#7702

On Monday January 4 2016 18:27, in comp.os.linux.misc, "The Natural
Philosopher" <tnp@invalid.invalid> wrote:

> On 04/01/16 23:07, no.top.post@gmail.com wrote:
[snip]
>> That's why *unix users say "try this..try that, it works for me,
>> I don't know why, but get lucky, be happy";
>> instead of "it is A...it is B".
>>
> You sound like the twats that invented PASCAL, They didnt want any
> inconsistencies, so they wrote an academically perfect language.
> 
> And then realised that an academically perfect language cant have any IO....
> 
> 
> C and UNIX were developed extremely fast by a couple of dedicated engineers.

With respect to your observation on PASCAL I/O, let me quote from "The C
Programming Language" by Brian W. Kernighan and Dennis M. Ritchie, (c) 1978
Bell Telephone Laboratories:

  "C provides no operations to deal directly with composite objects such as
   character strings, sets, lists, or arrays considered as a whole. There is
   no analog, for example, of the PL/1 operations which manipulate an entire
   array or string. The language does not define any storage allocation
   facility other than static definition and the stack discipline provided by
   the local variables of functions: there is no heap or garbage collection
   like that provided by Algol 68. Finally, C itself provides no input-output
   facilities: there are no READ or WRITE statements, and no wired-in file
   access methods. All of these higher-level mechanisms must be provided by
   explicitly-called functions."
 
It is interesting to note that, like PASCAL, the C language (the original
language as documented by K&R v1) does not provide I/O facilities.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.os.linux.debian

csiph-web