Recursive search in directories

[DrWaleedAYousef]

Thanks for the grest package.

I have never been successful in recursive search in subdirectories. I tried

• C-x C-d (after helm-find-files)
• "..name/" as the help says In both cases, it prompts me for Pattern: and then nothing happen.

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

Thanks for the grest package.

I have never been successful in recursive search in subdirectories. I tried

• C-x C-d (after helm-find-files)

No.

• "..name/" as the help says In both cases, it prompts me for Pattern: and then nothing happen.

Assume helm-find-files is bound to C-x C-f.

1) C-x C-f

Find files or url: /home/you/

2) Find files or url: /home/you/..name/

3) You should have now (with a recursive minibuffer)

/home/you/somedir/some/otherdir/name1 /home/you/somedir/some/otherdir/name2

4) Hit RET on /home/you/somedir/some/otherdir/name1

5) you are now with helm-find-files to:

Find files or url: /home/you/somedir/some/otherdir/name1

Thierry

[thierryvolpiatto]

Here some screenshots illustrating this:

[DrWaleedAYousef]

Thanks so much for fast reply,

The behavior I get is different. After step (2), I get a prompt:

Pattern:

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

Thanks for the grest package.

I have never been successful in recursive search in subdirectories. I tried

• C-x C-d (after helm-find-files)

No.

• "..name/" as the help says In both cases, it prompts me for Pattern: and then nothing happen.

Assume helm-find-files is bound to C-x C-f.

1) C-x C-f

Find files or url: /home/you/

2) Find files or url: /home/you/..name/

3) You should have now (with a recursive minibuffer)

/home/you/somedir/some/otherdir/name1 /home/you/somedir/some/otherdir/name2

4) Hit RET on /home/you/somedir/some/otherdir/name1

5) you are now with helm-find-files to:

Find files or url: /home/you/somedir/some/otherdir/name1

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

This is using locate as backend, are you sure you have a locate running with a ready to use database ?

[DrWaleedAYousef]

First, I really thank you for your detailed reply and time.

I have locate with locate.db located at home directory.

Thierry Volpiatto notifications@github.com writes:

This is using locate as backend, are you sure you have a locate running with a ready to use database ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[DrWaleedAYousef]

moreover, (to help you tracing) the following succeed:

1- C-x C-f 2- C-u C-x C-f (it starts helm locate recursively)

Waleed Yousef wyousef@fcih.net writes:

First, I really thank you for your detailed reply and time.

I have locate with locate.db located at home directory.

Thierry Volpiatto notifications@github.com writes:

This is using locate as backend, are you sure you have a locate running with a ready to use database ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[xuchunyang]

Works for me on Ubuntu. I didn't know helm-file-files can do this before. On my system, the default database is located at /var/lib/mlocate/mlocate.db according to the manpage.

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

moreover, (to help you tracing) the following succeed:

1- C-x C-f 2- C-u C-x C-f (it starts helm locate recursively)

C-u C-x C-f starts helm-locate but with a local db (offer to create one if none), for a whole locate search use only C-x C-f.

Of course to use helm-find-files => /home/you/..name/ and have some output, you have to ensure you have existing directories called "name*" under /home/you and these directories are recorded in the locate database.

Thierry

[DrWaleedAYousef]

I tried with locate.db at home and /var/lib/mlocate/mlocate.db

Only C-x C-f or C-u C-x C-f work. However, ..name/ does not work at all!!

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

moreover, (to help you tracing) the following succeed:

1- C-x C-f 2- C-u C-x C-f (it starts helm locate recursively)

C-u C-x C-f starts helm-locate but with a local db (offer to create one if none), for a whole locate search use only C-x C-f.

Of course to use helm-find-files => /home/you/..name/ and have some output, you have to ensure you have existing directories called "name*" under /home/you and these directories are recorded in the locate database.

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

I tried with locate.db at home and /var/lib/mlocate/mlocate.db

Only C-x C-f or C-u C-x C-f work. However, ..name/ does not work at all!!

Did you try from ./emacs-helm.sh ?

Describe again what you are doing step by step, you may do something wrong.

Once we find what's wrong we will be able to improve documentation and correct what confused you.

Thierry

[DrWaleedAYousef]

Sorry, what is ./emacs-helm.sh ?

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

I tried with locate.db at home and /var/lib/mlocate/mlocate.db

Only C-x C-f or C-u C-x C-f work. However, ..name/ does not work at all!!

Did you try from ./emacs-helm.sh ?

Describe again what you are doing step by step, you may do something wrong.

Once we find what's wrong we will be able to improve documentation and correct what confused you.

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

It is a shell script you should have in your helm directory. 1) cd /your/helm/directory 2) ./emacs-helm.sh

[thierryvolpiatto]

From a console of course.

[DrWaleedAYousef]

I tried it; same behavior. I opened the /home/MY/locate.db and made sure that it has the directories I am trying to use in ..name/

I do not know what is the problem

Thierry Volpiatto notifications@github.com writes:

From a console of course.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[DrWaleedAYousef]

Just to confirm the steps:

1- C-x C-f (helm-find-files)

2- /home/MY/..name/ (where name is some directory EXISTS in some path under MY; then once I add the last slash "/" helm should display the recursive folders containing "name")

right?

Waleed Yousef wyousef@fcih.net writes:

I tried it; same behavior. I opened the /home/MY/locate.db and made sure that it has the directories I am trying to use in ..name/

I do not know what is the problem

Thierry Volpiatto notifications@github.com writes:

From a console of course.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

Just to confirm the steps:

1- C-x C-f (helm-find-files)

2- /home/MY/..name/ (where name is some directory EXISTS in some path under MY; then once I add the last slash "/" helm should display the recursive folders containing "name")

right?

Yes looks good. Maybe check the helm-locate-recursive-dirs-command and see if it is a command supported with the locate version provided by your OS.

Thierry

[DrWaleedAYousef]

I may have a clue; I always get a message:

locate -e --regex SOMETHING set: Warning: path component /usr/local/bin:/usr/bin may not be valid in PATH.

My .bashrc has the following:

export PATH="$PATH:/usr/local/bin"

What is wrong in that? Is that related to our problem?

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

Just to confirm the steps:

1- C-x C-f (helm-find-files)

2- /home/MY/..name/ (where name is some directory EXISTS in some path under MY; then once I add the last slash "/" helm should display the recursive folders containing "name")

right?

Yes looks good. Maybe check the helm-locate-recursive-dirs-command and see if it is a command supported with the locate version provided by your OS.

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[DrWaleedAYousef]

Also, when I do C-c / it works but it gives me at the beginning of the buffer:

/home/wyousef/set: Did you mean 'set PATH $PATH /usr/bin'?

Waleed Yousef wyousef@fcih.net writes:

I may have a clue; I always get a message:

locate -e --regex SOMETHING set: Warning: path component /usr/local/bin:/usr/bin may not be valid in PATH.

My .bashrc has the following:

export PATH="$PATH:/usr/local/bin"

What is wrong in that? Is that related to our problem?

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

Just to confirm the steps:

1- C-x C-f (helm-find-files)

2- /home/MY/..name/ (where name is some directory EXISTS in some path under MY; then once I add the last slash "/" helm should display the recursive folders containing "name")

right?

Yes looks good. Maybe check the helm-locate-recursive-dirs-command and see if it is a command supported with the locate version provided by your OS.

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

export PATH="$PATH:/usr/local/bin"

Try:

export PATH=${PATH}:/usr/local/bin

but I guess you don't have to set this yourself, on most distributions, /usr/local/bin is already in PATH.

What is wrong in that? Is that related to our problem?

Of course, if locate on command line is not working, there is no chances that it works in helm, or in emacs more generally.

Thierry

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

/home/wyousef/set: Did you mean 'set PATH $PATH /usr/bin'?

I guess find, locate and many others program are confused with a wrong setting of PATH on your system.

Thierry

[DrWaleedAYousef]

One more clue: I am using fish; are all these correlated?

Waleed Yousef wyousef@fcih.net writes:

Also, when I do C-c / it works but it gives me at the beginning of the buffer:

/home/wyousef/set: Did you mean 'set PATH $PATH /usr/bin'?

Waleed Yousef wyousef@fcih.net writes:

I may have a clue; I always get a message:

locate -e --regex SOMETHING set: Warning: path component /usr/local/bin:/usr/bin may not be valid in PATH.

My .bashrc has the following:

export PATH="$PATH:/usr/local/bin"

What is wrong in that? Is that related to our problem?

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

Just to confirm the steps:

1- C-x C-f (helm-find-files)

2- /home/MY/..name/ (where name is some directory EXISTS in some path under MY; then once I add the last slash "/" helm should display the recursive folders containing "name")

right?

Yes looks good. Maybe check the helm-locate-recursive-dirs-command and see if it is a command supported with the locate version provided by your OS.

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

One more clue: I am using fish; are all these correlated?

Hmm, I know nothing about fish, is it reading .bashrc and friends ?

Thierry

[DrWaleedAYousef]

UPDATE:

The problem of the locate.db is solved; this was due to the existence of a very weird directory under home whose name was "set: Warning: path .."; very funny I know.

So, now there is no problem in the path, locate, shell, or any other thing. However, the "..name/" recursive issue still exists!!

I tried looking at the elisp code of helm-locate and helm-find. Are you sure there is no bug in the string:

helm-locate.el#:100:(defcustom helm-locate-recursive-dirs-command "locate -i -e -A --regex ^%s %s.*$"

I am not sure (I am not expert in LISP)

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

UPDATE:

The problem of the locate.db is solved; this was due to the existence of a very weird directory under home whose name was "set: Warning: path .."; very funny I know.

So, now there is no problem in the path, locate, shell, or any other thing.

Is locate working when used on command line ?

However, the "..name/" recursive issue still exists!!

I tried looking at the elisp code of helm-locate and helm-find. Are you sure there is no bug in the string:

helm-locate.el#:100:(defcustom helm-locate-recursive-dirs-command "locate -i -e -A --regex ^%s %s.*$"

I am sure, if there was a bug there other people and me as well would have the same issue than you. However as I said verify in a terminal such command is supported by your locate version.

BTW why are you showing the autosave version of helm-locate.el (#helm-locate.el#) ? Is helm properly installed ?

Thierry

[DrWaleedAYousef]

It works very well with no errors or warnings.

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

UPDATE:

The problem of the locate.db is solved; this was due to the existence of a very weird directory under home whose name was "set: Warning: path .."; very funny I know.

So, now there is no problem in the path, locate, shell, or any other thing.

Is locate working when used on command line ?

However, the "..name/" recursive issue still exists!!

I tried looking at the elisp code of helm-locate and helm-find. Are you sure there is no bug in the string:

helm-locate.el#:100:(defcustom helm-locate-recursive-dirs-command "locate -i -e -A --regex ^%s %s.*$"

I am sure, if there was a bug there other people and me as well would have the same issue than you. However as I said verify in a terminal such command is supported by your locate version.

BTW why are you showing the autosave version of helm-locate.el (#helm-locate.el#) ? Is helm properly installed ?

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

It works very well with no errors or warnings.

So I see no reasons why it is not working from emacs until I have more infos.

Is your fish shell supporting regexps in the same way as emacs (gnu regexp) ?

Thierry

[DrWaleedAYousef]

I am now using bash until we solve this issue

On Oct 31, 2016 1:05 PM, "Thierry Volpiatto" notifications@github.com wrote:

Waleed Yousef notifications@github.com writes:

It works very well with no errors or warnings.

So I see no reasons why it is not working from emacs until I have more infos.

Is your fish shell supporting regexps in the same way as emacs (gnu regexp) ?

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/emacs-helm/helm/issues/1635#issuecomment-257267036, or mute the thread https://github.com/notifications/unsubscribe-auth/ALpbzaibAovPOaWWCVxUxYY9G4_uAUd7ks5q5cuVgaJpZM4KkTH0 .

[michael-heerdegen]

Waleed Yousef notifications@github.com writes:

I am now using bash until we solve this issue

It is not a good idea to let Emacs execute shell commands with fish. fish is a shell with non-standard syntax; this would break stuff in different regards. I can only advice to not let Emacs use it for the execution of shell commands.

It is not a problem to use fish as your default shell, but AFAIR then you should set the variable "shell-file-name" to a standard shell, like "/bin/bash", to be used by Emacs internally for executing shell commands. You can still use fish in M-x term (though fish doesn't work so well in M-x shell), so it doesn't make a difference in practice.

I use fish myself as interactive shell, it is great, the problem is just that lisp programs calling "shell-command" and friends expect a sh-like shell evaluating their stuff.

[xuchunyang]

How about running locate without through shell? (start-process/call-process-shell-command -> start-process/call-process)

[DrWaleedAYousef]

Thanks so much for the good general advice; I will do this.

Michael Heerdegen notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

I am now using bash until we solve this issue

It is not a good idea to let Emacs execute shell commands with fish. fish is a shell with non-standard syntax; this would break stuff in different regards. I can only advice to not let Emacs use it for the execution of shell commands.

It is not a problem to use fish as your default shell, but AFAIR then you should set the variable "shell-file-name" to a standard shell, like "/bin/bash", to be used by Emacs internally for executing shell commands. You can still use fish in M-x term (though fish doesn't work so well in M-x shell), so it doesn't make a difference in practice.

I use fish myself as interactive shell, it is great, the problem is just that lisp programs calling "shell-command" and friends expect a sh-like shell evaluating their stuff.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

Michael Heerdegen notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

I am now using bash until we solve this issue

It is not a good idea to let Emacs execute shell commands with fish.

Thanks for clarifications.

Thierry

[thierryvolpiatto]

Chunyang Xu notifications@github.com writes:

How about running locate without through shell? (start-process/call-process-shell-command -> start-process/call-process)

Not sure to understand what you want to do.

On our side I don't think we should try to handle such cases, we already had a similar issue on Windows where a user was using a bash shell with a command needing a Windows console (es).

Just help user setting a sane configuration if needed, no more.

Thierry

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

I am now using bash until we solve this issue

So is it working now with bash as default shell ? If not did you update your db (updatedb) ?

Thierry

[DrWaleedAYousef]

First, let me thank you so much for your patience and support.

BTW, I am using ArchLinux. I did all the following steps, in order, and still does not work!!

• deleted locate.db
• changed the shell to bash (both the default shell of booting and of
• emacs using (setq shell-file-name /bin/bash))
• deleted all helm packages then re-installed them
• rebooted
• now I am on bash (and did not go to X)
• ./emacs.d/elpa/helmxxxxxxx/emacs-helm.sh
• C-x C-f
• C-u C-x C-f (to create a new locate.db)
• pattern: SomeDirIhave (it populates all possible findings recursively and nicely in the buffer)
• However: C-x C-f then ..SomeDirIhave/ it looks like searching but nothing appear in the buffer and prompts me for pattern:

I really fed up;

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

I am now using bash until we solve this issue

So is it working now with bash as default shell ? If not did you update your db (updatedb) ?

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[michael-heerdegen]

Waleed Yousef notifications@github.com writes:

• emacs using (setq shell-file-name /bin/bash))

Did you use the correct syntax (setq shell-file-name "/bin/bash") ?

[michael-heerdegen]

Waleed Yousef notifications@github.com writes:

• pattern: SomeDirIhave (it populates all possible findings recursively and nicely in the buffer)
• However: C-x C-f then ..SomeDirIhave/ it looks like searching but nothing appear in the buffer and prompts me for pattern:

And does that mean that helm-locate works in general, but not the ..DIR/ syntax? Does it always fail, or only sometimes? BTW, you can see the executed shell command if you M-x trace-function call-process-shell-command RET. Try it from a shell to see if it fails there, too, and what could possibly be wrong.

(FWIW, the ..DIR/ thingy seems to fail when the current path contains symlinks)

[DrWaleedAYousef]

Yes; I used the right syntax (I just composed the email not copied and pasted from .emacs). This is exactly (copied and pasted) what I have in my emacs:

(setq explicit-shell-file-name "/bin/bash" ;;shell called with M-x shell shell-file-name "/bin/bash") ;;shell used by Emacs

Michael Heerdegen notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

• emacs using (setq shell-file-name /bin/bash))

Did you use the correct syntax (setq shell-file-name "/bin/bash") ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[DrWaleedAYousef]

Yes, helm-locate works for everything except ..DIR/ thing.

Regarding simlink issue, I tried from different directories; same behavior.

I tried your tracing suggestion as follows for one of my directories /home/wyousef/MyDocuments/MESC

• C-x C-f
• Find files or url: /home/wyousef/..MESC/

• it gives me the following (exactly copied from the message buffer):

  Recursively searching MESC from ~/ ...

• and then asks for pattern in the mini buffer while the main buffer does not contain any suggested recursive folders!
• and the trace-output is this:

1 -> (call-process-shell-command "locate -i -e -A --regex ^/home/wyousef/ MESC.*$" nil t nil) 1 <- call-process-shell-command: 1

• I then copied the command of locate above literally to the shell of Emacs (I tried both M-x shell and M-x eshell); it does not give any output (I think because of missing -d locate.db):

  locate -i -e -A --regex ^/home/wyousef/ MESC.*$

• I then tried the same from shell after adding -d locate.db it worked very well:

  locate -d locate.db -i -e -A --regex ^/home/wyousef/ MESC.*$

• I hard-coded the option into helm file:

helm-locate.el:101:(defcustom helm-locate-recursive-dirs-command "locate -d locate.db -i -e -A --regex ^%s %s.*$"

Still does not work and moreover the new syntax is not shown in the tracing output (may be this is not the line called for ..DIR/; I am not sure):

1 -> (call-process-shell-command "locate -i -e -A --regex ^/home/wyousef/ MESC.*$" nil t nil) 1 <- call-process-shell-command: 1

What do you think is missing?

Michael Heerdegen notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

• pattern: SomeDirIhave (it populates all possible findings recursively and nicely in the buffer)
• However: C-x C-f then ..SomeDirIhave/ it looks like searching but nothing appear in the buffer and prompts me for pattern:

And does that mean that helm-locate works in general, but not the ..DIR/ syntax? Does it always fail, or only sometimes? BTW, you can see the executed shell command if you M-x trace-function call-process-shell-command RET. Try it from a shell to see if it fails there, too, and what could possibly be wrong.

(FWIW, the ..DIR/ thingy seems to fail when the current path contains symlinks)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[fice-t]

@michael-heerdegen

I use fish myself as interactive shell, it is great, the problem is just that lisp programs calling "shell-command" and friends expect a sh-like shell evaluating their stuff.

FWIW this .. functionality does not work for me with zsh as my shell-file-name. With bash it works as expected.

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

What do you think is missing?

It seems you have created a locate.db locale file (what is the path of this locate.db ?) and you have no global db file, normally your system should have a locate script which run daily and create a db for the whole system in "/var/lib/(m)locate".

So no your locate command is actually not functional, you get some results because you ran your command in a directory containing a db you specified with -d, but it seems you have no db file. I asked you if you ran updatedb, so I ask again, did you ran it ? But anyway even if you run it your system should do this for you automatically.

Thierry

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

• now I am on bash (and did not go to X)

What do that mean "did not go on X" ?

• ./emacs.d/elpa/helmxxxxxxx/emacs-helm.sh
• C-x C-f
• C-u C-x C-f (to create a new locate.db)

No, helm doesn't need a locale locate db, this db is locale to your current directory and doesn't contain the infos to find a directory below your current one.

Thierry

[thierryvolpiatto]

fice-t notifications@github.com writes:

FWIW this .. functionality does not work for me with zsh as my shell-file-name. With bash it works as expected.

Hmm, I am not expert with these exotic shells, but perhaps zsh is not supporting multiples patterns (i.e passed with "--regex" option and printed with "-A" option) or it try to do some clever completion when a space is entered in command line. If so "locate -i -e --regexp ^%s --regexp %s.*$" should work but much slower.

Thierry

[michael-heerdegen]

Thierry Volpiatto notifications@github.com writes:

Hmm, I am not expert with these exotic shells, but perhaps zsh is not supporting multiples patterns (i.e passed with "--regex" option and printed with "-A" option)

Aren't these arguments all passed to locate? Abilities of the shell should not make a difference as long as the arguments are passed to locate unaltered.

or it try to do some clever completion when a space is entered in command line.

AFAIK zsh has much more clobbing abilities than other shells. My guess is that our regexp patterns are interpreted as globbing patterns and substituted by something different (a possibly empty file list or something like that) before locate is called. Quoting the regexps should help then.

[michael-heerdegen]

Thierry Volpiatto notifications@github.com writes:

So no your locate command is actually not functional, you get some results because you ran your command in a directory containing a db you specified with -d, but it seems you have no db file. I asked you if you ran updatedb, so I ask again, did you ran it ? But anyway even if you run it your system should do this for you automatically.

Running locate from the command line from different directories should reveal if that is the case.

FWIW, some locate implementations allow to disregard certain directory trees when building the database. But AFAIK you need to configure it to do so.

[DrWaleedAYousef]

Ok, now I did the following:

• deleted locate.db (to test the mlocate.db)
• from shell I did: updatedb --require-visibility 0

This created /var/lib/mlocate/mlocate.db which is owned by myself and mlocate is owned by myself as well.

• from shell, I tried:

locate -i -e -A SomeDir

it does not find except those Dirs under the root and above my username. Same behavior is obtained via C-x C-f C-x C-f

• ..name/ options does not work even when I do: /..name/ (i.e., from the root)

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

What do you think is missing?

It seems you have created a locate.db locale file (what is the path of this locate.db ?) and you have no global db file, normally your system should have a locate script which run daily and create a db for the whole system in "/var/lib/(m)locate".

So no your locate command is actually not functional, you get some results because you ran your command in a directory containing a db you specified with -d, but it seems you have no db file. I asked you if you ran updatedb, so I ask again, did you ran it ? But anyway even if you run it your system should do this for you automatically.

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[DrWaleedAYousef]

Thierry Volpiatto notifications@github.com writes:

I mean by X, windows manager (I use awesome). So I tried everything from shell right after booting.

How comes locate.db (that is created right under the home directory /home/wyousef/locate.db) does not have this info, while locate runs well from shell (without having /var/lib/mlocate/mlocate.db) using the same command captured by call-process-shell-command

locate -i -e -A --regex ^/home/wyousef/ MESC.*$

Waleed Yousef notifications@github.com writes:

• now I am on bash (and did not go to X)

What do that mean "did not go on X" ?

• ./emacs.d/elpa/helmxxxxxxx/emacs-helm.sh
• C-x C-f
• C-u C-x C-f (to create a new locate.db)

No, helm doesn't need a locale locate db, this db is locale to your current directory and doesn't contain the infos to find a directory below your current one.

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[thierryvolpiatto]

Waleed Yousef notifications@github.com writes:

• from shell I did: updatedb --require-visibility 0

Why complicating ? Just run "updatedb" no more.

Thierry

[thierryvolpiatto]

Michael Heerdegen notifications@github.com writes:

Thierry Volpiatto notifications@github.com writes:

Hmm, I am not expert with these exotic shells, but perhaps zsh is not supporting multiples patterns (i.e passed with "--regex" option and printed with "-A" option)

Aren't these arguments all passed to locate?

It should but not sure with zsh, with bash yes of course it works.

Abilities of the shell should not make a difference as long as the arguments are passed to locate unaltered.

or it try to do some clever completion when a space is entered in command line.

AFAIK zsh has much more clobbing abilities than other shells. My guess is that our regexp patterns are interpreted as globbing patterns and substituted by something different (a possibly empty file list or something like that) before locate is called.

Yes something like this.

Quoting the regexps should help then.

No we don't have to handle this at the helm level.

Thierry

[DrWaleedAYousef]

because it gives me this:

/usr/bin/updatedb: can not open a temporary file for `/var/lib/mlocate/mlocate.db'

I retried with adding my self to the group locate:

gpasswd -a wyousef locate

but it does not create as well

So, I had to create /var/lib/mlocate using sudo and ran updatedb using sudo then changed the owner of mlocate.db to wyousef (myself) (many get arounds to create it).

probably this is the problem!!

Thierry Volpiatto notifications@github.com writes:

Waleed Yousef notifications@github.com writes:

• from shell I did: updatedb --require-visibility 0

Why complicating ? Just run "updatedb" no more.

Thierry

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.*