Is it possible to make ls aware of the hidden file flag on Mac OS X?

Currently, a simple ls -lO produces:

$ ls -lO
total 0
drwxr-xr-x@  84 danielbeck  staff  -      2856 29 Mai 22:44 Applications
drwx------+ 158 danielbeck  staff  -      5372 29 Mai 15:27 Desktop
drwx------@ 250 danielbeck  staff  -      8500 30 Mai 20:40 Documents
drwx------+  11 danielbeck  staff  -       374 29 Mai 22:21 Downloads
drwx------@  84 danielbeck  staff  -      2856 29 Mai 22:48 Library
drwx------@   3 danielbeck  staff  hidden  102  3 Apr 20:45 Movies
drwx------@   5 danielbeck  staff  hidden  170  3 Apr 20:45 Music
drwx------+ 215 danielbeck  staff  -      7310 29 Mai 22:54 Pictures
drwxr-x---@   7 danielbeck  staff  hidden  238  3 Apr 20:45 Public
drwxr-xr-x@   4 danielbeck  staff  hidden  136 24 Apr 23:25 Sites

So we have three kinds of visibility: regular, visible files, files with the hidden file flag, that aren't actually hidden in Terminal, and really hidden files whose names start with a dot.

Is there a way, e.g. using an alias or a reliable shell function, to make ls treat hidden flagged and .dothidden files the same, i.e. hide by default and show with ls -A or ls -a, similar to how Finder behaves depending on the value of defaults read com.apple.Finder AppleShowAllFiles?

I am aware that man chflags specifically mentions hidden flag only hides from GUI, i.e. Finder.

link|improve this question

I guess you thought about combining ls, awk, grep and their likes? – slhck May 30 '11 at 21:31
@slhck If it's possible to do reliably, and without changing ls so much I'm restricted in how to use it, then that's an option. – Daniel Beck May 31 '11 at 4:45
Yeah, it sounds like that would be the way to go, and make it a terminal alias—maybe something like 'lsh' (for hidden). – pattern86 Jun 11 '11 at 6:26
2  
@pattern86 I actually thought about adapting my answer here to this, since the hidden attribute is also exposed via xattr -p com.apple.FinderInfo at a different offset. I might write a totally new ls script that does both colors and hidden flag ;) – Daniel Beck Jun 11 '11 at 6:30
1  
@FlorenzKley As I indicate in the comments, I'm fine with scripts and shell functions. – Daniel Beck Oct 1 '11 at 6:15
show 4 more comments
feedback

1 Answer

ok, let's try a bit of a laterally shifted approach. I did think about it a bit, and we might not be so far apart. It's just that I do it this way for about 10 years now, and hardly even think about it anymore.

  • your problem, reworded:

A finder window (presumably opening $HOME) and a Terminal window (also starting out in $HOME) show a different number of files and directories, which is inconsistent with each other. This problem gets even more pronounced as the 10.7 finder hides ~/Library, You could substitute other combinations here - Linux vs. BSD, KDE vs. Gnome, etc.

  • what you would like (your requirement):

Finder and CLI tools should display a consistent picture, i.e. the files and directories displayed by default should be the same (and it's not just ls - every tool should be able to stick to that consistency). And let's broaden that requirement to not only one platform's tools, but multiple machines/OS versions.

A fine mess. Let me elaborate:

I essentially had this problem for the last 20-odd years. I'm working on most commercially available Unix systems, a number of Linux distros, some BSD flavors, Mac OS and Windows. Each of those OS has it's own idea where "My Stuff" is located by default, what is considered a "Desktop", etc. But, as a timesaver, I depend on my stuff beeing in the same place, every time. Some of it is kept in an SCM, other things are static. I don't want the OS to mess with it, and I want a consistent location.

While the Unix systems seem "close" as compared to Windows, they are not. And when two different releases of the same put stuff in the same directories, things break when you try to share $HOME between those two, or more.

These "platform pecularities" are pretty well entrenched, and a lot of things depend on such pecularities to run. You will usually find those oddities when you do something differently, not according to "mainstream" (i.e., one computer and obe vendors OS should be enough for you), and in some cases you can't even fix them (vendor code base). The number of problems is too much to handle when you try to leave the mainstream here, and it's pretty thankless to report bugs against that - they will mostly fail triage when compared to "real breakage". So the best answer you might get when you complain about such things is "don't do that, then".

My solution: I have a number of personal folders that live in the top level of what the "My Stuff" folder of that platform is considered to be, usually one level down from $HOME. On Mac OS, it's ~/Documents

shiny:Documents fl$ ls -1
current
done
ideen
keller
reference
src
trampolin

I adjust the platform to open default windows in there (Mac OS: Finder preferences, "New Finder windows open: Documents"). My shell profile changes to this directory, too. And because I'm boss in here, I say what goes in, and what's hidden. I basically ignore $HOME on the first level, because I consider the dot files (which I link to src//dotfiles in some cases) and everything else to be under "platform control". Some of it get copied up to $HOME, some of it linked. No hard rules, needs a platform dependent decision.

That way, I can let the OS mess around in $HOME, and even share a $HOME between machines with different OS flavors, or software versions (beta versions of KDE and GNOME, or rather anything beta, is pretty tame that way).

makes sense :-) ?

link|improve this answer
It does make sense, and I'm sure there are a few I want to always keep my home directories synchronized topics that could also profit from this information, but still isn't what I actually want to achieve. It's simply a work-around that doesn't achieve what I actually want. It's not just the home directory that's affected — think e.g. about ls -lAO / and stuff like /Volumes, /usr, /private, /sbin showing on the command line. As it's not a real problem I face, I will hold out for a better solution. – Daniel Beck Oct 30 '11 at 14:18
I really appreciate your persistent wish to help me here, but as it's not really a problem I don't need workarounds that just sort of hide the issue. I hope this makes sense. – Daniel Beck Oct 30 '11 at 17:58
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.