I just discovered some mentions of how nautilus used to read files named .hidden and hide files matching the patterns listed in them, and at some point that feature was moved to GIO g_file_info_get_is_hidden. However, I haven't been able to get it to work. If I put the exact name of a file into .hidden, it does get hidden, but I'd really like to be able to use a pattern. I can't find any solid or recent documentation about how this feature is supposed to work.
I'd particularly like to hide files matching hg-checkexec-*. Mercurial running under Emacs periodically creates bunches of these temporary files and they gum up my nautilus view.
Is this feature documented anywhere? How is it supposed to work?
Looking at the code, .hidden files as implemented in GIO support one filename per line, with no support for patterns. A .hidden file cannot list files in subdirectories — only those in the same directory.
I don’t know of any documentation about the feature. Please file a bug about adding it.
As a complement to Philip Withnall's answer, I've dived further into the source code, specifically the functions read_hidden_file() and file_is_hidden():
read_hidden_file() basically parses the .hidden in a directory and stores each line in as a key in a GLib HashTable object.
The object is created using g_hash_table_new_full() with parameters g_str_hash, g_str_equal, g_free, NULL. This mean keys are plain strings with comparison being a plain (case-sensitive) string equality, so no globs, regex or any patterns support.
It is populated using g_hash_table_add(), so not used as a key/value pair table but rather as a plain set, with keys being the elements themselves.
file_is_hidden() is called for each content (file or sub-directory) in a given directory. It uses g_hash_table_contains() to check if the file's basename is a key in above object, so no pattern search whatsoever.
So, as Phillip concluded, it seems there is indeed no support for any kind of globs, regexes or pattern seach in .hidden files. I would also die for a .gitignore-like syntax.
Related
Basically I am looking for a way of "branding" a cfg file. Specifically a CSGO-config, so yes, nothing too important. I'm just surprised, that after quite a bit of google search, I still havent found anything.
In general, plain text files (and probably .cfg files) do not contain any metadata by default. The file system should keep track of some properties for these file types, but they won't otherwise transfer across filesystems.
If you would like to "brand" your file, perhaps you could add a comment to the top with your name. It would be about as permanent and immutable as any metadata anyways.
Doxygen has a \file command, I had a look at different code bases and it seems some projects use it, some don't.
Having to maintain this adds some overhead (needs to be corrected when splitting files up) sometimes developers forget to do it.
Is there a way to infer this, eg: use the first doxygen formatted comment in the file as the \file comment.
Otherwise what is a good rule of thumb for when to use \file or not?
Note, I tried removing this command from all files and the output changed to group information less usefully and the order of some information changed, so it does make a difference.
In org-mode, when I export to PDF or HTML, I'd like to specify the names of the resulting files. Ideally two separate names, one for the PDF, one for the HTML. Is this possible?
Chris's answer is out of date. There is now an EXPORT_FILE_NAME setting:
#+export_file_name: <filename>
If you put this at the start of your file (not in a subtree), it will name the entire file that when you export.
Edit: For newer versions of org-mode, see slondr's answer.
It doesn't look like you can specify a name for the exported file as a whole.
From the link, emphasis mine:
When exporting only a subtree, each of the previous keywords can be overriden locally by special node properties. These begin with ‘EXPORT_’, followed by the name of the keyword they supplant. For example, ‘DATE’ and ‘OPTIONS’ keywords become, respectively, ‘EXPORT_DATE’ and ‘EXPORT_OPTIONS’ properties. Subtree export also supports the self-explicit ‘EXPORT_FILE_NAME’ property [4].
[4] There is no buffer-wide equivalent for this property. The file name in this case is derived from the file associated to the buffer, if possible, or asked to the user otherwise.
I've read a lot about the tup build system.
In many places, it is said that tup "does not support recursive rules" and that you need to have one Tupfile per directory. Yet I have not seen an official statement or explanation.
Is the above claim correct?
If yes, why, and for which kind of task is this problematic? An example would be nice.
It is worth noting that currently a Tupfile can create files in a different directory. You could always read files from different directory, so currently you can have a single Tupfile for the whole project.
Some more info here: https://groups.google.com/d/msg/tup-users/h7B1YzdgCag/qsOpBs4DIQ8J (a little outdated) + https://groups.google.com/d/msg/tup-users/-w932WkPBkw/7ckmHJ9WUCEJ (new syntax to use the group as input)
If you use the new LUA parser you can also have a "default" Tupfile - see here http://gittup.org/tup/lua_parser.html and check info about Tupdefault.lua
Some of the answers have mentioned already that the limitation really is one Tupfile per directory where you want output files, instead of one Tupfile per directory. In a recent commit, this limitation has been relaxed and tup allows you to place output files also in subdirectories of the Tupfile.
In addition, with variants, it is possible to generate output files anywhere in the build tree.
The official statement can be found in tup manual: http://gittup.org/tup/manual.html
You must create a file called "Tupfile" anywhere in the tup hierarchy
that you want to create an output file based on the input files. The
input files can be anywhere else in the tup hierarchy, but the output
file(s) must be written in the same directory as the Tupfile.
(Quotation is the 1st paragraph from the section TUPFILES in the manual)
AFAIK, it is a limitation which has something to do with the way how tup stores dependencies in the .tup subdir but I don't know details.
Whenever I list the contents of a directory with a function like readdir, the returned file names also include "." and "..". I have the suspicion that these are just normal links in the file system and therefore indistinguishable from actual files, but I always have to filter them out because they are not actual objects in the directory I am listing. Is there a good reason for functions like readdir to include them? Do some operating systems or file systems contain more or different virtual file names? Is there a better way to filter them out other than by doing string comparison with "." and ".."?
Update: thank you all for answering. I suppose I always thought that things like ./ and ../ were mere conventions that could be handled by searching and replacing. I find it a bit surprising, though probably more efficient and transparent, to have them be part of the file system itself.
One question remains, though: since . and .. are arbitrary names for these links, are there file systems that use different ones?
. and .. are actually hard links in filesystems. They are needed so that you can specify relative paths, based on some reference path (consider "../sibling/file.txt"). Since these hard links are actually existing in the filesystem, it makes sense for readdir to tell you about them. (actually the term hard link just means some name that is indistinguishable from the actual directory referred to: they both point to the same inode in the filesystem).
Best way is to just strcmp and ignore them, if you don't want to list them.
Originally they were hard links, and the number of special cases in the filesystem code for . and .. were minimal. That's not true for all modern filesystems, however.
But the conventions have been established so that even filesystems where these two directory entries don't actually exist still report their existence through APIs like readdir. Changing this would now would break a lot of code.
I have the suspicion that these are
just normal links in the file system
and therefore indistinguishable from
actual files
They are. While you may perceive the file system as a hierarchy of "folders" "containing" folders, it is actually a doubly linked tree1, with directories being nodes and files being leafs. So, . and .. are needed links for accessing the leaves of the current node and for traversing the tree, and they are the same thing as all the other links.
When you call readdir, you get all the places you can directly go to from the current node. If you do not want to list places that you perceive as "up", you have to sort them out yourself. You should write a little function for that, perhaps called readdir_down. I do not know in which order readdir lists the directories, but perhaps you can just throw away the first two entries.
1) this is a first approximation, there are also "hard links" possible that make the tree actually a net.
One reason is that without them there is no way to get to the parent directory. Or get a handle to the current directory.
Without them, we cannot do such things as:
./run_this
Indeed, we couldn't add '.' to the $PATH, meaning we couldn't ever execute files that weren't already in the path.
These are normal directories, they are "hard links" to the current directory and directory above. They are present in all directories (even at the root level, where .. is exactly the same as .).
When using ls, you can filter out . and .. with ls -A (note the capital -A).
When applying a command to all dot-files, but not . or .., I often use .??* which matches only dot-file with a name of three characters or more.
touch .??*
Note this pattern also excludes any other file that begins with dot and is only two characters long (e.g. .x) but those files are uncommon.
When using programmatic file-listers like readdir() I do have to exclude . and .. manually. Since these two files are supposed to be first in the list returned by readdir() you can do this:
#files = readdir(DIR);
for (1..2) { shift #files; } # get rid of . and ..
# go on with your business
They are reported because they are stored in the directory listing. That's the way unices have always worked.
Because on Unix-like operating systems, the directory-listing commands include those, and you use them to move up and down in the filesystem hierarchy.
Something like grep { not /^.{1,2}\z/ } readdir HANDLE should work for you.
there is no good reason a directory scan should return these filenames.