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. 0 followers. amosa69 (78) is leader. Post Follow

25 Replies
424 Views

Similar Articles

[PageSpeed] 2

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:

Similar Artilces:

find.find
import fnmatch, os def find(pattern, startdir=os.curdir): matches = [] os.path.walk(startdir, findvisitor, (matches, pattern)) matches.sort() return matches def findvisitor((matches, pattern), thisdir, nameshere): # for name in nameshere: if fnmatch.fnmatch(name, pattern): fullpath = os.path.join(thisdir, name) matches.append(fullpath) can someone explain why (matches, pattern) is doing in this two funct? thanks In <eo15uq$hna$1@ss408.t-com.hr>, Gigs_ wrote: > import fnmatch, os > > def find(pattern, startdir=os...

Find::Find
I'm writing a script to process a directory tree of images.  In each directory, I need to process each image and generate an HTML file listing all of the images and links to the subdirectories. Just about every source I can find on the 'net for processing subdirectories points you at Find::Find.  However, I'm trying to do something like this: enter directory open INDEX, ".\index.html" print INDEX HTMLheader foreach file{         if(file is an image){  ...

Find.find does not find orphaned links?
Find.find does not seem to find orphaned links: Downloads>ln -s /nonexistent Downloads>ls -l total 0 lrwxrwxrwx 1 wybo users 12 Nov 15 14:15 nonexistent -> /nonexistent Downloads>irb irb(main):001:0> require 'find' => true irb(main):002:0> Find.find('.') do |f| puts f end Hi, In message "Re: Find.find does not find orphaned links?" on Tue, 15 Nov 2005 22:19:59 +0900, Wybo Dekker <wybo@servalys.nl> writes: |Find.find does not seem to find orphaned links: It's a bug. Thank you. matz. ...

help on find over find
hi all I have a problem trying to do the following: MyModel.find(:all).find(:first) it can look weird or unnecesary but this is the short explanation, extended one is: I have a helper method, this receives a collection an return some html, this helper works fine if that collection is an association (has_many) of a model but doesn't work if it is a direct find over a model the error I receive is "LocalJumpError: no block given" ultra mega extended explanation is: a model: class User < ActiveRecord::Base has_many :requests end other model: cla...

Find.find bug?
$ ruby -rfind -e 'Find.find("foo") {|e| p e}' "foo" $ ls foo C:\msys\1.0\local\bin\ls.exe: foo: No such file or directory It should return nothing if foo doesn't exist. martin Hi, At Wed, 8 Sep 2004 00:45:09 +0900, Martin DeMello wrote in [ruby-talk:111751]: > > $ ruby -rfind -e 'Find.find("foo") {|e| p e}' > "foo" > > $ ls foo > C:\msys\1.0\local\bin\ls.exe: foo: No such file or directory > > It should return nothing if foo doesn't exist. What version ruby do you run? $ LANG=C ls foo ls: foo:...

FIND finds too much
% The problem, easily seen below, is the unexpected behavoir of FIND. % DTA is an 1152x17 matrix whose details should not, it seems to me, be important. A1=find(DTA(:,2)==+1&DTA(:,3)==-1); DTA(A1(1:2),2:3),DTA(A1(end-1:end),2:3) ans = 1 -1 1 -1 ans = 1 -1 1 -1 % So far so good, only 1 -1 combinations present (directly verified for ALL entries, % in DTA(A1,:), not just those shown here). But then A2=find(DTA(A1,4)==DTA(A1,5)); DTA(A2(1:2),2:3),DTA(A2(end-1:end),2:3); ans = 1 -1 1 -1 ans = 1 1 1 1 % Why...

Linux complaints: easy to find. Linux praise: hard to find
Why is it so easy to find huge collections of Linux complaints (virtually every forum of every distro), but you can't find big collections of Linux positive reviews? I can go to www.newegg.com right now and find 1000+ positive reviews (~70% of total) of Windows Vista. What it tells me is hardly anyone uses Linux, and those that do use it have lots of problems. Wait... haven't I said that before? On Mon, 17 Mar 2008 11:27:24 -0500, DFS wrote: > Why is it so easy to find huge collections of Linux complaints > (virtually every forum of every distro), but you can't fi...

When Find finds something -
- it sometimes highlights the thing and sometimes puts a little dotted box around it. What's the difference? It's very hard to see the dotted box sometimes and I have to Find it visually! Is there a way to change this "found" indicator to make it more conspicuous? Thank you in advance. Steve Gray On Apr 23, 2:12 am, Steve Gray <stev...@roadrunner.com> wrote: > - it sometimes highlights the thing and sometimes puts a > little dotted box around it. What's the difference? It's very hard to > see the dotted box sometimes and I have t...

finding find.c
comp.os.minix finding find.c Anyone know where the source for find is. I've been looking on 2.0.2 and haven't been able to find it. Hul I found it. Find, for some reason, can't find itself unless its given an explicit name. Hul Hul Tytus <ht@panix.com> wrote: > comp.os.minix > finding find.c > Anyone know where the source for find is. I've been looking on 2.0.2 and > haven't been able to find it. > Hul ...

How to exclude action of Find::Find::find in subdirectories with known names? 219620
I must pass through directory tree and to execute some action with files, names of which described by regex. I need not do it in directories SCCS and VVS, which can be in every subdirectory. The following code works correctly, does not action ("THE ACTION") in unwanted directories, but it pass through every subdirectory. I'd would like that it will worked faster, and procedure "wanted" will not step inside SCCS and VVS. I have tried for that purpose the "untaint_pattern" and "untaint_skip" options but did not success. Perhaps I used incorre...

How to exclude action of Find::Find::find in subdirectories with known names? 136296
I must pass through directory tree and to execute some action with files, names of which described by regex. I need not do it in directories SCCS and VVS, which can be in every subdirectory. The following code works correctly, does not action ("THE ACTION") in unwanted directories, but it pass through every subdirectory. I'd would like that it will worked faster, and procedure "wanted" will not step inside SCCS and VVS. I have tried for that purpose the "untaint_pattern" and "untaint_skip" options but did not success. Perhaps I used incorrect values. Or, I do not understand the task of the options correctly. Somebody can suggest to me the decision? Thanks in advance, --Vadim ...

"Find" does not find
Hello, I am pretty desperate, since I do not know what I am doing wrong. I unsuccessfully checked several sites and forums and the FAQ.: I'll try to reduce to the problem. I use a Matrix M with: [16000 6]= size(M) I need to access a certain subset of the Matrix M: idx =find(M(:,1)==x); This works fine. BUT: i generalized and used that code in a 'for'-loop: x=[40.1:0.1:55] for x idx=find(M(:,1)==x) % any evaluating command comes here ...

Help find you I Can not find
Saying on the Internet about the stukovinu as virtual stripteas impose the search gave me plenty of poschelkal and all the different prices and th extra dollars to pay not want some Pro write this kidala and I spent about an hour and does no want one site is not found Posovetuiti send to passion as, in fac I found it is one saitik scas briefly about him speak, Zaregistrirovalsa [URL=http://sex-635f4.live-nude-cam-chat.info] here [/URL] I will se what the girls me one I liked zaplotil not much denujku Then write it, and almost ohuel what it is I Ves presentation had as this. And once zaplotiv I liked, an now I buy them girls I like what that was al Yes good site. I there the days han ...

Find Find and Beagle Not Working
Yes, You know it. Suse 10/Gnome, and they don't work. You can't search for a file. LMAO. They need a daemon. Really, they are a demon. Seems like this should be a DEFAULT SETUP. I gotta go an TWEAK again. tab wrote: > Yes, > > You know it. > Suse 10/Gnome, and they don't work. > You can't search for a file. LMAO. > > They need a daemon. Really, they are a demon. > Seems like this should be a DEFAULT SETUP. > > I gotta go an TWEAK again. More bullshit. The way to search for a file is to use find/locate/whereis. KDE has KFind as the GUI f...

how to resume Find.find after a failure?
If a file is unreadable on Linux, Find.find seems to skip it and move to the next file. However, if a file is unreadable on Windows, Find.find seems to raise an exception, and I see no way to go to the next file: C:\temp>ruby -e 'puts RUBY_VERSION' 1.8.1 C:\temp>mkdir foo bar baz C:\temp>echo > bar\file1.txt C:\temp>echo > baz\file2.txt C:\temp>echo > foo\file3.txt C:\temp>ruby -rfind -e "Find.find('.') { |f| p f }" "." "./foo" "./foo/file3.txt" "./baz" "./baz/file2.txt" "./bar&qu...

Find Usages
Just noticed the find usages dialog isn't showing ALL usages of a method: http://stumpy.talios.com/~amrk/dolphin-find-usages.png In here, the method #useOutlookProfileSettings: is called where its highlighted, but also a bit lower down, why isn't it mentioned in the list? Is it because there both in the same #initialize method? Mark "Mark Derricutt" <talios@gmail.com> wrote in message news:cpaggb$urg@library1.airnews.net... > Just noticed the find usages dialog isn't showing ALL usages of a method: > > http://stumpy.talios.com/~amrk/...

find it, cut it out, find next
I have a string that contains numbers and ranges of numbers, like '1 2 4-6 8 20 - 23' which translates as "include numbers 1, 2, 4, 5, 6, 8, 20, 21, 22, 23' I can find the range "objects" with while ($s =~ /(\d+ *- *\d+)/g) { # work with $1 } Is there a way to trim up this string during the loop so that when it's done, the range "objects" are gone and I'm left with the discreet list of digits. It would look like this when complete '1 2 8' I can trim it up later with s/(\d+ *- *\d+)//g, but was wondering if this could be a one step t...

Finding a lost PYTHONPATH with find
OK, this is really a reminder to myself next time I forget where I set my PYTHONPATH and forget exactly how to invoke the GNU "find" command ;-) Hope somebody else finds it useful too find / -maxdepth 3 -size -100k -type f -exec grep -sli pythonpath '{}' \; The minus in '-100k' (meaning "less than 100k") seems to be undocumented, at least on my system. I suppose the -maxdepth is redundant since I think find searches breadth-first by default. The file I was looking for turned out to be in /etc/profile.d/, whose existence I completely forgot about... J...

Finding a Book (Was Finding an App
Since I only have around thirty apps, finding one in a group generally isn't a problem. However, I've sometimes had significant problems in remembering where to find the book I'm currently reading. I've got most of the collections by author or series within author. Unfortunately if it's a new author and a first read, being able to return to it can be a problem. My work around is having a "Currently Reading" collection and moving books in and out of it when I'm reading them. What I'd like to see is a change to the "Books" display in...

Find and Find Again in Acrobat 6 (and up)?
Is there an option or user preference one can set in Acrobat 6 (and up) for the Mac that will restore the more familiar operations of Find and Find Again -- that is, cmd-F takes you to the first (or maybe the next) example of the search string in the document, cmd-G steps you down through any further examples -- rather than bringing up a separate window listing all the search results? I much prefer the older version, for various reasons, and hope it's not gone entirely . . . ? AES <siegman@stanford.edu> wrote: >Is there an option or user preference one can set in Acrobat ...

Find.find and files in cwd
I can use Find.find(Pathname.getwd) to get an array of all file paths recursively, but how do I get only the files in the cwd (do not recurse into sub-directories)? Thank you, Brad rtilley wrote: > I can use Find.find(Pathname.getwd) to get an array of all file paths > recursively, but how do I get only the files in the cwd (do not > recurse into sub-directories)? Dir provides several ways to do this: http://www.ruby-doc.org/core/classes/Dir.html On Mar 21, 2006, at 1:18 PM, rtilley wrote: > I can use Find.find(Pathname.getwd) to get an array of all file > paths recursively, but how do I get only the files in the cwd (do > not recurse into sub-directories)? Try: Dir["#{Dir.getwd}/*"] Hope that helps. James Edward Gray II rtilley wrote: > I can use Find.find(Pathname.getwd) to get an array of all file paths > recursively, but how do I get only the files in the cwd (do not recurse > into sub-directories)? Check out Dir (http://ruby-doc.org/core/classes/Dir.html) Dir.pwd #=> current directory Dir['*'] #=> contents of current directory (files and directories) Cheers James Edward Gray II wrote: > On Mar 21, 2006, at 1:18 PM, rtilley wrote: > >> I can use Find.find(Pathname.getwd) to get an array of all file paths >> recursively, but how do I get only the files in the cwd (do not >> recurse into sub-directories)? > > > Try: > > Dir["#{Dir.getwd}/...

Find.find, limited recursion..
[Note: parts of this message were removed to make it a legal post.] Hi all, I'm working on a script that's currently using Find.find to process a complete directory tree of files and directories .. .however I needed specific behavior, and I'm still fairly new to this... Basically it works like this, the user specifies the root directory of a collection of sub-directories we are interested in .. for instance: User specifies: C:\Root C:\Root | -->\Dir1 | -->Files_in_dir1 | -->\Dir2 ...

Find not finding .h files
I'm Finding that in one of my projects every time I do a multi-file Find, I get warnings "Unable to open file" for the vast majority of .h files in the project (over 100). You can use command-D to open any of those files, and those very same files compile succesfully. Problems occur only for project headers, not system headrs. I haven't gotten around to trying the usual gamut of "fix damaged project" kind of things, but since this problem only seems to involve Find functionality whereas everything compiles fine, it seems a little different and I thought ...

Found a Find.find() bug?
I was trying out Find.find() today and found that if you pass it a directory without a trailing slash, it doesn't traverse the directory. This seems like a bug to me. Is it? If so, how do I report it? e.g. require 'find' Find.find("/tmp/") do |path| puts path end vs. require 'find' Find.find("/tmp/") do |path| puts path end On Fri, 16 Feb 2007, Garance A Drosehn wrote: > On 2/15/07, robertlaferla@comcast.net <robertlaferla@comcast.net> wrote: >> >> I was trying out Find.find() today and found that if you ...

Web resources about - mc finds more than `find` finds? - comp.os.linux.misc

'SNL' sums up what 'real Americans' say about Donald Trump with 'Racists for Trump' parody
Donald Trump has come under intense fire in the past week over his refusal to disavow racist groups and supporters, such as KKK leader David ...

Celebrities React to Nate Diaz Defeating Conor McGregor in UFC 196
Celebrities have been sending out tweets reacting to Nate Diaz ‘s shocking win against fellow fighter Conor McGregor during UFC 196 held at the ...

'Girls' Star Lena Dunham Hospitalized, The Latest On Her Health
Starpulse.com 'Girls' Star Lena Dunham Hospitalized, The Latest On Her Health Starpulse.com "Girls" star Lena Dunham has been hospitalized. ...

Scientists discover 'ghostlike' octopus that appears to belong to a previously unknown species
National Geographic Scientists discover 'ghostlike' octopus that appears to belong to a previously unknown species Economic Times WASHINGTON: ...

Kim Kardashian Says 'People v O.J. Simpson' Moment 'Absolutely Did Not Happen'
Kim Kardashian takes a trip to Toys R Us with her daughter North West (not pictured) on Saturday (March 5) in Woodland Hills, Calif. The 35-year-old ...

Dog pops up in driver's seat in US
One dog apparently has learnt a new trick: how to drive a semi-truck.

Peyton to announce retirement after 18-year career
Denver Broncos quarterback Peyton Manning will announce his retirement from the NFL at a news conference in Denver on Monday, bringing an end ...

Germany rejects calls to give Greece more time for budget goals
Germany has rejected calls to give Greece more time to reach budget goals agreed with international lenders for its third bailout program as ...

Joey Feek Enjoys Dolly Parton Parton Surprise Video In Rory Feek’s First Farewell Message
Joey Feek has gone to heaven but not all her memories are sad. In his first blog post since his wife’s death, Rory Feek told the sad news . Then ...

Suicide Bomber Kills at Least 47 Near Baghdad
Wall Street Journal Suicide Bomber Kills at Least 47 Near Baghdad Wall Street Journal BAGHDAD—A truck bomb exploded at a crowded checkpoint ...

Resources last updated: 3/6/2016 3:40:45 PM