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 2 of 2 — ← Prev page 1 [2]

#7725

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]

#7421

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]

#7437

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]

#7672

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 | alt.os.linux.debian

csiph-web