-1

"Hidden files" are files with name prefix ., e.g. /home/pxf/.xxx. .xxx is an invisible file and 'ls' will not list it.

Is there a concept of "hidden file" On Linux Kernel? I mean that are there difference between "regular files" and "hidden files"?

Or just it's a conventional rule that a file with prefix . will not be shown by default such as ls. (except with -a option)?

jww
  • 97,681
  • 90
  • 411
  • 885
TanakaYasen
  • 139
  • 7
  • No, there is nothing special about it. It is just basically a "hint" for software to not show it unless the user requests for it, but it makes no difference. So the last sentence in your question is correct. – Iskar Dec 29 '16 at 10:17
  • 1
    Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/) or [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) would be a better place to ask. Also see [Where do I post questions about Dev Ops?](http://meta.stackexchange.com/q/134306) – jww Dec 29 '16 at 13:45
  • Historically, it started out as a bug in `ls` which was never fixed because people started using it as a feature. Instead `ls` gained the `-a` flag – slebetman Dec 29 '16 at 13:49

1 Answers1

3

See Wikipedia: Hidden file and hidden directory

They are not a security mechanism because access is not restricted - usually the intent is simply not "clutter" the display of the contents of a directory listing with files the user did not directly create.

This is just a convenient convention that application may or may not observe. The invisibility of these files is not enforced by the kernel.

xhienne
  • 5,738
  • 1
  • 15
  • 34
  • So is the Environment Variable 'PATH' just a **convention** for shell searching executable files too? – TanakaYasen Dec 29 '16 at 13:50
  • @TanakaYasen: Yes, specifically there are shells (or shell-like programs) where the path variable is a different name. It's also what causes a lot of surprise to people using things like `cron` because some software execute the command string directly without invoking a subshell (that's possible because C has an execve function) – slebetman Dec 29 '16 at 13:54
  • @slebetman `cron` does not execute the command directly. It invokes a shell which executes the command. What is generally unexpected with `cron` is that `PATH` is not read from the user's rc files; it is set to a minimal value instead. As for the C functions, there are `execlp`, `execvp` and `execvpe` which do search the executable in the `PATH` environment variable. Those are not system calls (kernel functions) though. – xhienne Dec 29 '16 at 15:18
  • @slebetman `PATH` is not just a convention. It's [part of the POSIX standard](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08): *This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for an executable file known only by a filename...* It's [effect on the `exec` family of functions is specified](http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html): *the path prefix for this file is obtained by a search of the directories passed as the environment variable `PATH`* – Andrew Henle Dec 30 '16 at 00:34
  • @AndrewHenle Yes, but the POSIX standard is just a convention as well. As I said, there are shells where the executable path is not managed by a variable called PATH. tcl is one example. Before you say that's a language, not a shell note that bash is a language as well. And there is (or used to be) a distro of linux that uses tclsh as the default shell (the only shell installed in fact, that distro does not even use init, it replaced the init process with a tcl script) – slebetman Dec 30 '16 at 03:55