f



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?







0
WhoCares
11/28/2015 12:37:49 AM
comp.os.linux.misc 33599 articles. 1 followers. amosa69 (78) is leader. Post Follow

25 Replies
1467 Views

Similar Articles

[PageSpeed] 51

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

>
>
>
>
>
>
>
0
William
11/28/2015 12:52:45 AM
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

0
marrgol
11/28/2015 1:22:19 AM
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
0
Arkadiusz
11/28/2015 4:15:50 PM
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?



0
William
11/28/2015 5:59:54 PM
--=-=-=
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 {}'
    {}

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWWe1SAAoJEHGdadMkU5RQvsoP/0Ao/sMlDY2Y3/fTUwlknBmy
qHZj/M6D345JxxoTkLZ5b+C1QCO07om3xLUrNkwC/yE0Y67GNMIoEuO9ok9XRx3X
ipjaWE9l91BL9SrURyUWUr0nC0jPdG8kbbuEkTL+skqqVFeEfBe9ou5J7bKCUYMd
7p0P4i+k+/Bfsez5saf15kBXKRGpc+fjw9hyY5OW0sZOJHMqGRqve07HXMyCrfio
vsS+MY8v8DbrEjSyyeNs6iGT0dc/iDAdjdjYpsQsBbTrE1kkYsFTWqeSn5j+ZnPz
4s8KsHc/Tzqo6OKE2tK4aAHUwBjnkWe+I+NJX+GupoMkhBLF+fwbGAwrTb4RguSE
4jhpB9jp95OkwjUtiQqopb6AmqofSFam+BQwBROeyM1jOn+qXQPul6dGGJbkFW03
oYZejLGDYDEjJOY5OOn4GRYLJbeZX+PqrSgssGYgwHhPIE9hT3Fu6J2gOftPpRsv
VqgJ4sJHoGyeUoA3B2WSaUCN3I0/i00c3VKGutyivzlNj8gvCD6ijMKS8R9hqWmz
soYWFRtOpepJtJm+SIid5lJE5ZNys5pyWkdBEJ24ZvZOszCXX7jxuFKeAv2sAYdj
iW1/JlSGAOvquUb3hyQcGEkhlNPgJfj8vgWcmJVuMPPzpk9Fw7sGmKo2Q2mQgHCw
Z++XAIoL3G9K0EmjQ09X
=611G
-----END PGP SIGNATURE-----
--=-=-=--
0
Teemu
11/28/2015 6:07:02 PM
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
0
Arkadiusz
11/28/2015 6:14:37 PM
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. 

0
William
11/28/2015 8:44:39 PM
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
0
floyd
11/28/2015 8:52:26 PM
--=-=-=
Content-Type: text/plain

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.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWWtZvAAoJEHGdadMkU5RQzmgQAIR5V2Rn/jRozUZeUApHFekR
amm8Mn54OAm7+Qc/doJjdfBVVcT9URURI7YoNrfRK33PDNfhR0ISS5X1cMJ6khKc
1IhY+NNkJgpfAf0sK1IcWYYRlLRujbj9uIyQRmCMjP8EKxolUWicMLTDUCHUTE1r
Hpwkx3rECSwXMAk5LEbAl2umVrR7+ZUZ/vi6LjSxxEey+U/fCbf4Yrh6Rc51Ob7F
Ed1f/WzGdMsynomf26Qizeqjikjcnko/DZoLajqJtPXb2Qxu78CKDH0Oqd/1dULR
yEMgguB+/W0h4iv0xEjjYudq/cHmrkKmlTrtW8t4dnVqk3vKCpfW3foyHdLjAnus
dPIWnwtnb3IY5Ji/QbF+yBwh+/6/7a64dRAETKTRpvMFjOVd1dgG6z08htrCj3Ma
19sSz/ya53rZWtJYsn4l8Mw8ztipwWtlhcvEPFhg8E5NTShuSdUSJ9QTDWCjPNic
uuo8q051sRpyyeTe8oPjNM1Y0hK9JdRfFyC7B49q+fFk/FhBZk2cBY/5VZqf7Mtg
5PCe4aPlaiEC6zg8iBK1vY6aquwNfLw/wmaN6IRCUYAaDqBDGPBo+or1+52XMZfx
n/FnCCkSIPwRxNPSbULKIk74t9Q0Y2gltPwoJNDAq3/gBKCMOrRPvCQiGLhDvDre
yq/UZHf0q+0xbW9Xgcw6
=Hofi
-----END PGP SIGNATURE-----
--=-=-=--
0
Teemu
11/29/2015 10:41:45 AM
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.
0
Martijn
11/29/2015 3:35:16 PM
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
0
floyd
11/29/2015 7:49:44 PM
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. 

0
William
11/29/2015 8:07:25 PM
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.
0
Eef
11/29/2015 8:10:43 PM
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/
0
Richard
11/29/2015 8:24:15 PM
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
0
floyd
11/29/2015 11:09:56 PM
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/
0
Richard
11/30/2015 9:24:59 AM
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.
0
Eef
11/30/2015 10:08:18 AM
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
0
Joe
11/30/2015 3:59:09 PM
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>.

0
Unknown
1/3/2016 12:52:01 PM
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".

0
no
1/4/2016 11:07:53 PM
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


0
The
1/4/2016 11:27:02 PM
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

0
Lew
1/5/2016 12:28:05 AM
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/
0
Richard
1/5/2016 1:01:01 AM
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
0
The
1/5/2016 2:04:18 PM
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.
0
Jerry
1/5/2016 9:05:06 PM
Reply: