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

Groups > comp.os.linux.misc > #16380 > unrolled thread

mc finds more than `find` finds?

Back to article view | Back to comp.os.linux.misc

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? The Natural Philosopher <tnp@invalid.invalid> - 2016-01-05 14:04 +0000
                    Re: mc finds more than `find` finds? Richard Kettlewell <rjk@greenend.org.uk> - 2016-01-05 18:12 +0000
                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 2 of 2 — ← Prev page 1 [2]

#16673

On 05/01/16 00:28, Lew Pitcher wrote:
> 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.
>

Not providing them is not the same as deciding that they cannot be provided.

As with all things kernighan and Ritchie, they decided that most elegant 
compromise was to place IO inside of the operating system nit the 
language, and Unix provided that, and all C had to do was provide a 
library of interfaces to the operating system.

In short they took a pragmatic and efficient solution, while the purists 
were still puzzling over the 'best' way to solve an intractable problem 
they had created.

C was kept minimal. If you wanted extra, you built a library.

They didn't try and make the language enforce anything on anyone.

Some people like that freedom. Other people want to be told exactly what 
to do.



-- 
Ideas are more powerful than guns. We would not let our enemies have 
guns, why should we let them have ideas?

Josef Stalin

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

#16682

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> 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.

Sort of...

There’s a language-vs-library distinction, which makes the observation
that the language doesn’t provide any I/O primitives somewhat
uninteresting.

Looking beyond that distinction, however, the volume you quote also
talks of the “standard C I/O library [...] supported on all machines
that support C”.  It seems to me that the idea of a freestanding
implementation, formalized in 1989, must have been a later introduction.

Pascal, on the other hand, had I/O support built into the language
(i.e. not just a library component) in its earliest versions.  See
s6.2.4 of Wirth’s 1970 description of the language, for a start.

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

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

#16691

In alt.os.linux.slackware 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".
> 
But that's not unix, that's the command shell. Perhaps you'd be
happier using cmd.exe running in a vm.

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

#16382

On 2015-11-28 01:37, 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.

Have you tried `fuser "/path/to/certain file"` ?


-- 
mrg

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

#16412

On Sat, 28 Nov 2015 00:37:49 +0000, WhoCares 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" {} \;
>  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?

Are you looking for file names or file content? Find looks at names
then your exec'd grep will look at content in the found files. If you
want to search by file names do

  for PID in `pgrep wily`; do find /proc/$PID -name "CONTROL" -print >> trace; done

or

  for PID in `pgrep wily`; do find /proc/$PID -print|grep "CONTROL" >> trace; done

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

#16658

On Mon, 30 Nov 2015 15:59:09 +0000, Joe Beanfish wrote:

> On Sat, 28 Nov 2015 00:37:49 +0000, WhoCares 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" {} \;
>>  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?
> 
> Are you looking for file names or file content? Find looks at names then
> your exec'd grep will look at content in the found files. If you want to
> search by file names do
> 
>   for PID in `pgrep wily`; do find /proc/$PID -name "CONTROL" -print >>
>   trace; done
> 
> or
> 
>   for PID in `pgrep wily`; do find /proc/$PID -print|grep "CONTROL" >>
>   trace; done
------------
I'm wondering how/why I failed to explain what's required - because it's 
unusual?
Let's not waste effort, by partially completed journeys....
So I opened a wily on dir: /mnt/h15/var/CONTROL/
BTW I'm writing/testing this in wily now.
Like its example-that-plan9-copied: ETHO; <your written text is live/
executable>
For your 2 examples, "trace" is created -- but is empty.

-> HasOpenPath2: lsof | grep wily | grep CONTROL |awk '{print $1 " : "  
$2 " : "  $9 }'
== wily : 4272 : /mnt/h15/var/CONTROL

-> find /proc/4272 -exec grep  "CONTROL" {} \;  == nX:<nothing>

!?!? but when I open `mc` in /proc/4272 , and <search> string "CONTROL", 
I find:
 /proc/4272/environ =>
File: environ     Line 1 Col 3121    3587 bytes ==...
h15/usr/local/bin/wily.LC_COLLATE=C.PWD=/mnt/h15/var/CONTROL.INPUTRC=/etc/
input
--
So as seems reasonable: pid:4272 has PWD=/mnt/h15/var/CONTROL in its env

But HOW to print-out from 'dotty files'?
--------- I've just had a partial CRASH, and have lost details.
BTW, I'm wrong. This doesn't lead to the solution of: which WorkSpace has 
the
mc, which is currently open [with either of its 2 panels] on 
<stringInPATH>.

Consider the problem: you've got 20 WS/Desktops open, with 
`pgrep mc| wc -l` == 22
and some info arrives for <topicN> which you believe is ALREADY <open>
in some mc; but you need to know WHICH WS to open to get *that* mc.
Scrolling blackbox's WS-menu shows you which WS has a LIVE [one of 2]
panel on <topicN>. Advanced/smart-arse WMs show nothing. 

Where the mc was launched from [apparently in the env] is of no interest,
which is what my above test show.
BTW-BTW !! wily showed a <non returning proc> for 
   find /proc/4272 -exec grep  "CONTROL" {} \;
Messing with /proc/* is not advised?

Now I've copied /proc/<pid>/environ where I can investigate 
 how to grep it:
-> grep CONTROL /root/.pan2/article-cache/environ
== Binary file /root/.pan2/article-cache/environ matches

But as stated: mc let's you look inside <dotty files>.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.misc

csiph-web