8 Answers
8

This will append every directory in your ~/code tree to the current path. I don't like the idea myself, preferring to have only a couple of directories holding my own executables and explicitly listing them, but to each their own.

If you want to exclude all directories which are hidden, you basically need to strip out every line that has the sequence "/." (to ensure that you don't check subdirectories under hidden directories as well):

This will stop you from getting directories such as ~/code/level1/.hidden/level3/ (i.e., it stops searching within sub-trees as soon as it detects they're hidden). If you only want to keep the hidden directories out, but still allow non-hidden directories under them, use:

Nice, but same comment as for Vardhan... that is I need to exclude hidden directories. Also, what is the purpose of the piping the result of tr to sed?
–
user50264Mar 18 '09 at 6:11

hes trimming the last : so it doesn't produce a bogus path
–
Kent FredricMar 18 '09 at 6:13

1

you'd probably want to use find -print0 | tr "\0" ":" there instead Pax, then you'll have a filter that should work on ALL valid unix paths ( including ones with pesky newlines in them )
–
Kent FredricMar 18 '09 at 6:29

Very. Nice. Any way to exclude hidden directories? I'm have a git repo, so trying it out I got many more directories than I was expecting :-/
–
user50264Mar 18 '09 at 6:00

1

No reason to have find print with '\n's -- better to tell it to colon-separate the files in the first place.
–
Charles DuffyMar 18 '09 at 7:27

@user50264 - the same way you'd do any kind of exclusion with git; for instance: find "$root" -name ".[a-z]*" -prune -o -type d -printf '%p:' to exclude dotfiles matching the given pattern (excluding . is unwise, and the given hack is a passable 80% solution to avoid it).
–
Charles DuffyFeb 28 '11 at 2:35

I've been looking for a solution to this problem too. It would be great if bash had a way to say that for certain paths, you want it to search for the files recursively. For example

PATH="$PATH:/usr/local/bin:~/bin**"

where ~/bin would search that directory and all of its subdirectories without making a mess out of your PATH variable.

Since that's not implemented, my temporary solution is to put everything in my bin directory and then create another directory "bindir" that contains symbolic links to the actual executables in "bin", but their arranged neatly into subdirectories to make them easier to find.

My only question is whether I should hard links instead of symbolic links.

I have a single bin directory $HOME/bin and that gets an installed copy of any programs I build (or scripts, or symlinks to programs or scripts). It currently has almost 600 commands in it (ls | wc -l says 604, but there are a dozen or so sub-directories for various reasons).

When I'm testing a program, I execute it where I build it; once I've done testing for the time being, I acquire it with my acquire script, which copies the file and sets the permissions on it.

This leaves me with a nice tidy profile (I don't use .bashrc; I'd rather do the setup once when the login shell starts, and the sub-shells inherit the working environment without having to parse .bashrc again), but a rather ungainly bin directory. It avoids the cost of resetting PATH each time a shell starts, for example, and given how complex my path-setting code is, that is just as well!

which recursively echos all files that are descendant of the current dir.

Beware it does tend to bail out on overly complicated dirs sometimes, so use the ** at the lowest recucurring point.

echo **/

Coincidentally, emits recursively all directory names, and only directory names. ( Excluding the current dir )

echo ./**/

Includes the current dir. ( Incidentally, it also skips hidden directories )

This should thuswise be suited for creating a path string:

echo ./**/ | sed 's/\s\s*/:/g'

And if you don't want relative paths,

echo $PWD/**/ | sed 's/\s\s*/:/g'

Ack

From your comment on one of the other posts it sounds like you're wanting behaviour much like 'Ack' provides. If you were intending to use a find + grep combination, this tool is generally much more efficient and easier to use for this task.

Was not aware of either of those, is there a way to make either output directories?
–
user50264Mar 18 '09 at 6:16

I like this solution for its brevity, however I think I might have a different version of sed than you, it replaces the first "s" is each directory with a colon. But kudos for making me upgrade to bash 4.0 :)
–
user50264Mar 19 '09 at 0:48

O_o. Thats not a very complicated regex :S. \s\s* is supposed to just replace spaces.
–
Kent FredricMar 19 '09 at 3:54

@Kent - \s is PCRE syntax; it isn't supported in either basic or extended POSIX REs, and thus not by standard sed.
–
Charles DuffyFeb 16 '11 at 7:17