[gentoo-user] Re: locate can not find a file

2017-03-16 Thread Grant Edwards
On 2017-03-15, Kai Krakow  wrote:
> Am Wed, 15 Mar 2017 21:41:41 + (UTC)
> schrieb Grant Edwards :
>
>> On 2017-03-15, Kai Krakow  wrote:
>> 
>> > Especially people coming from Windows or DOS have problems with this
>> > feature. In the MS world, globbing expansion is done by the command
>> > itself: it will see the * literally in the parameters.  
>> 
>> Well, technically, that depends on what shell you're running.  That's
>> true with the command.com and cmd.exe shells.  It's not true with some
>> others.
>> 
>> When back when I ran DOS (and when I run Windows), the globbing is
>> done by the shell: the way god intended.  ;)
>
> Hell yeah! :-)
>
> Tho I'd expect that globbing done by the shell won't play well with
> most traditional DOS commands. I guess those shells also brought their
> own built-in commands?

Yes, those shells came with a complete set of command line utilities
(ls, find, grep, cat, ed, awk, ...).

Under DOS, I always ran MKS Toolkit (korn shell):

  https://en.wikipedia.org/wiki/MKS_Toolkit

On Windows, I use Cygwin (bash shell).  I have vague memories of using
Interix for a while, but that may have been just for the X server.

And, back in my VMS days, I used DECShell (a Posix shell and complete
set of unix utilities).

-- 
Grant Edwards   grant.b.edwardsYow! ANN JILLIAN'S HAIR
  at   makes LONI ANDERSON'S
  gmail.comHAIR look like RICARDO
   MONTALBAN'S HAIR!




[gentoo-user] Re: locate can not find a file

2017-03-15 Thread Kai Krakow
Am Wed, 15 Mar 2017 15:52:53 -0600
schrieb the...@sys-concept.com:

> On 03/15/2017 03:36 PM, Kai Krakow wrote:
> > Am Wed, 15 Mar 2017 16:31:58 +0100
> > schrieb Alarig Le Lay :
> >   
> >> On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote:  
>  [...]  
> >>
> >> Hi,
> >>
> >> Do you have file consent_extraction1.pdf in your working
> >> directory? In that case, your shell will begin by expending your
> >> asterisk and you will really look for consent_extraction1.pdf.  
> > 
> > This is a concept many people cannot or don't want to grasp. Easy
> > fix is to put quotation marks around the search term:
> > 
> > # locate "consent_extraction*"
> > 
> > Especially people coming from Windows or DOS have problems with this
> > feature. In the MS world, globbing expansion is done by the command
> > itself: it will see the * literally in the parameters.
> > 
> > In the GNU world, globbing expansion is done by the shell before
> > handing parameters over to the command: The command won't see the *
> > but instead sees what the shell made from it. To work around this
> > behavior, you simply put quotation marks around it (which will be
> > removed before handed over to the command, so even
> > consent_extraction"*" would work).
> > 
> > Thus, simply always put quotation marks if you don't want to become
> > fooled by unwillingly letting the shell do its job. Missing to do so
> > can even have some negative effects, i.e. dangerous, like
> > overwriting files during mv by moving all files into the same
> > filename.  
> 
> locate "consent_extraction*" - didn't find anything
> 
> I think, by default "locate" wants to enclose the search location
> between two "*.*" stars.  So if you will not put anything locate
> will put them for you.  If you put  only one star it will not find
> anything.

Not true... But it seems globbing is working different in locate
(well, technically speaking, it works different as expected):

The star always matches against the complete path, not only one path
fragment. That is why it doesn't work for you.

Use the following and it should work:

# locate $(pwd)/"consent_extraction*"

If you put a star in front, it will also match the $(pwd) component.

On the shell, omitting the star in the front only works because you are
already in that directory. The shell omits this part of the path when
matching. To make this clear, doing:

# cd ..
# ls consent_extraction*

wouldn't find your file, too. But using:

# cd ..
# ls */consent_extraction*

would. As does locate...

-- 
Regards,
Kai

Replies to list-only preferred.




[gentoo-user] Re: locate can not find a file

2017-03-15 Thread Kai Krakow
Am Wed, 15 Mar 2017 21:41:41 + (UTC)
schrieb Grant Edwards :

> On 2017-03-15, Kai Krakow  wrote:
> 
> > Especially people coming from Windows or DOS have problems with this
> > feature. In the MS world, globbing expansion is done by the command
> > itself: it will see the * literally in the parameters.  
> 
> Well, technically, that depends on what shell you're running.  That's
> true with the command.com and cmd.exe shells.  It's not true with some
> others.
> 
> When back when I ran DOS (and when I run Windows), the globbing is
> done by the shell: the way god intended.  ;)

Hell yeah! :-)

Tho I'd expect that globbing done by the shell won't play well with
most traditional DOS commands. I guess those shells also brought their
own built-in commands?

-- 
Regards,
Kai

Replies to list-only preferred.




Re: [gentoo-user] Re: locate can not find a file

2017-03-15 Thread Neil Bothwick
On Wed, 15 Mar 2017 15:52:53 -0600, the...@sys-concept.com wrote:

> I think, by default "locate" wants to enclose the search location
> between two "*.*" stars.  So if you will not put anything locate
> will put them for you.  If you put  only one star it will not find
> anything.

No need to think or suppose, the man page explains it clearly:

If --regex  is not specified, PATTERNs can contain globbing characters.
If any PATTERN  contains no globbing characters, locate  behaves as if
the pattern were *PATTERN*.


-- 
Neil Bothwick

And on the seventh day God said :wq and then make


pgpf1psSdFep3.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Re: locate can not find a file

2017-03-15 Thread thelma
On 03/15/2017 03:36 PM, Kai Krakow wrote:
> Am Wed, 15 Mar 2017 16:31:58 +0100
> schrieb Alarig Le Lay :
> 
>> On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote:
>>> Yes, I run as root: updatedb
>>> But when run:
>>> locate consent_extraction*
>>>
>>> It only list one file:
>>> /home/fd/consent_extraction1.pdf (this is a link file)
>>> /home/fd/business/forms/consent_extraction1.pdf
>>>
>>> It can not find: "consent_extraction.pdf" both files are in same
>>> directory
>>>
>>> ll business/forms/
>>> total 688
>>> ...
>>> -rw-r--r-- 1 fd fd  63032 Mar 15 08:52 consent_extraction1.pdf
>>> -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf
>>>
>>> I observe the same behaviour on my local machine and remote machine.
>>>
>>> Running "find" finds both files
>>>
>>> find . -name '*consent_extraction*'
>>> ./business/forms/consent_extraction.pdf
>>> ./business/forms/consent_extraction1.pdf
>>> ./consent_extraction1.pdf
>>>
>>> Why?  
>>
>> Hi,
>>
>> Do you have file consent_extraction1.pdf in your working directory? In
>> that case, your shell will begin by expending your asterisk and you
>> will really look for consent_extraction1.pdf.
> 
> This is a concept many people cannot or don't want to grasp. Easy fix
> is to put quotation marks around the search term:
> 
> # locate "consent_extraction*"
> 
> Especially people coming from Windows or DOS have problems with this
> feature. In the MS world, globbing expansion is done by the command
> itself: it will see the * literally in the parameters.
> 
> In the GNU world, globbing expansion is done by the shell before
> handing parameters over to the command: The command won't see the * but
> instead sees what the shell made from it. To work around this behavior,
> you simply put quotation marks around it (which will be removed before
> handed over to the command, so even consent_extraction"*" would work).
> 
> Thus, simply always put quotation marks if you don't want to become
> fooled by unwillingly letting the shell do its job. Missing to do so
> can even have some negative effects, i.e. dangerous, like overwriting
> files during mv by moving all files into the same filename.

locate "consent_extraction*" - didn't find anything

I think, by default "locate" wants to enclose the search location
between two "*.*" stars.  So if you will not put anything locate
will put them for you.  If you put  only one star it will not find anything.

--
Thelma



[gentoo-user] Re: locate can not find a file

2017-03-15 Thread Grant Edwards
On 2017-03-15, Kai Krakow  wrote:

> Especially people coming from Windows or DOS have problems with this
> feature. In the MS world, globbing expansion is done by the command
> itself: it will see the * literally in the parameters.

Well, technically, that depends on what shell you're running.  That's
true with the command.com and cmd.exe shells.  It's not true with some
others.

When back when I ran DOS (and when I run Windows), the globbing is
done by the shell: the way god intended.  ;)

-- 
Grant Edwards   grant.b.edwardsYow! HELLO KITTY gang
  at   terrorizes town, family
  gmail.comSTICKERED to death!




[gentoo-user] Re: locate can not find a file

2017-03-15 Thread Kai Krakow
Am Wed, 15 Mar 2017 16:31:58 +0100
schrieb Alarig Le Lay :

> On mer. 15 mars 09:10:26 2017, the...@sys-concept.com wrote:
> > Yes, I run as root: updatedb
> > But when run:
> > locate consent_extraction*
> > 
> > It only list one file:
> > /home/fd/consent_extraction1.pdf (this is a link file)
> > /home/fd/business/forms/consent_extraction1.pdf
> > 
> > It can not find: "consent_extraction.pdf" both files are in same
> > directory
> > 
> > ll business/forms/
> > total 688
> > ...
> > -rw-r--r-- 1 fd fd  63032 Mar 15 08:52 consent_extraction1.pdf
> > -rw-r--r-- 1 fd fd 397649 Mar 14 20:05 consent_extraction.pdf
> > 
> > I observe the same behaviour on my local machine and remote machine.
> > 
> > Running "find" finds both files
> > 
> > find . -name '*consent_extraction*'
> > ./business/forms/consent_extraction.pdf
> > ./business/forms/consent_extraction1.pdf
> > ./consent_extraction1.pdf
> > 
> > Why?  
> 
> Hi,
> 
> Do you have file consent_extraction1.pdf in your working directory? In
> that case, your shell will begin by expending your asterisk and you
> will really look for consent_extraction1.pdf.

This is a concept many people cannot or don't want to grasp. Easy fix
is to put quotation marks around the search term:

# locate "consent_extraction*"

Especially people coming from Windows or DOS have problems with this
feature. In the MS world, globbing expansion is done by the command
itself: it will see the * literally in the parameters.

In the GNU world, globbing expansion is done by the shell before
handing parameters over to the command: The command won't see the * but
instead sees what the shell made from it. To work around this behavior,
you simply put quotation marks around it (which will be removed before
handed over to the command, so even consent_extraction"*" would work).

Thus, simply always put quotation marks if you don't want to become
fooled by unwillingly letting the shell do its job. Missing to do so
can even have some negative effects, i.e. dangerous, like overwriting
files during mv by moving all files into the same filename.

-- 
Regards,
Kai

Replies to list-only preferred.


pgphDhknqNGIY.pgp
Description: Digitale Signatur von OpenPGP