I may need to develop some short snippets/examples involving reading text files; so I thought - why not use some files that are typically present on all (and since I sense "all" may be a stretch, then "most" is fine) Linux "vanilla" systems/distros? (primarily interested in Linux here)

The only one I can think of for now is /etc/fstab - however, it should be owned by root, so I'm not sure whether that will interfere with my snippets later on - I'd like an average user to at least be able to read them (although, fstab's permissions are -rw-r--r--, so I don't think read-only would be a problem; for instance, cat /etc/fstab works fine under my regular username). Another reason why I wouldn't like to use it, is because it contains potentially sensitive information...

In any case, I was wondering - are there any other text-files that could be considered "standard" in typical GNU/Linux systems, that I could use for this purpose? (basically, something like example.com, but on your local filesystem)

  • 1
    There are many such files, probably. But why not create your own example files? One file that is commonly available in any system that uses a bash shell, as most Linux-based Os's do, is .bashrc. Jan 10, 2014 at 15:29
  • Thanks for the comment, @FaheemMitha - I was precisely trying to avoid creating own example files.. .bashrc looks like a good suggestion, though ... Cheers!
    – sdaau
    Jan 10, 2014 at 15:40
  • 1
    A surprising number of system files are world readable. I suppose this fits in with the idea that "security through obscurity" (eg., by concealing configuration details) is not worth bothering with too much.
    – goldilocks
    Jan 10, 2014 at 15:43
  • 1
    @goldilocks Debian's take (in debian.org/doc/manuals/securing-debian-howto/ch12.en.html). "The current policy regarding log files and configuration files is that they are world readable unless they provide sensitive information." I'm too lazy to see if policy says anything specific about this. Jan 10, 2014 at 16:07

4 Answers 4


This is tricky, because while many text files may be present in most Linux systems, they are not necessarily guaranteed to be in the same place. @tintifaxx's /proc answer is good since this will work on all but the oldest/most oddly configured kerneks.

That said, here are some fairly safe bets in /etc


Also /proc/mounts is a good one because calling mount does very minimal formatting on this and so could be a good short snippet.


If you are looking for files available in the user's home directory, you can do:

graeme@graeme:~$ ls -a /etc/skel
.  ..  .bash_logout  .bashrc  .profile

These files are copied in to the user's home when the account is created, so you can expect them to be there for every user on the system. .profile is more ubiquitous than bash. The problem with these files though is that if they are written to by accident, this could be a problem.

  • Thanks for that, @Graeme - I also mentioned in other comments: pretty much all in /etc is owned by root (even if it is world readable), and pretty much all in /proc has an actual file size 0 (even if it produces content upon, say, cat), and I've seen problems with that before (maybe APIs that seek to end of file before reading); and I'd like to avoid these possible stumbling blocks... Good to have a nice list of some other /etc candidates though - cheers!
    – sdaau
    Jan 10, 2014 at 16:38
  • Yeah, saw your comment about /proc just after I posted this, didn't know about that. I would say /etc is better because it is not writeable by normal users, as changing any of these common files is potentially problematic.
    – Graeme
    Jan 10, 2014 at 17:17

when it's only about read-only you could try some "virtual" files in the proc filesystem, e.g /proc/cpuinfo, /proc/filesystems or /proc/meminfo. They should be readable by anyone in general. They're also nice to parse and to extract useful information.

  • Many thanks for the answer @tintifaxx - however, I think all of the files in /proc report a file size of 0; and now I remember I actually think I tried them once long ago (cannot remember exactly in what context or with what program, unfortunately); and whatever program I was using failed, I think it was because if was trying to seek to the end of file first... so I'd still appreciate a suggestion for a "proper" text file. Good to keep this in mind though - cheers!
    – sdaau
    Jan 10, 2014 at 15:38

Unix-like systems running the bash shell by default, like all "mainstream" Linux-based operating systems do, to my knowledge, generally ship with a non-empty .bashrc template which is placed by default in any users home directory. This by default world readable, but in any case is always readable by that user.

  • Many thanks for the answer, @FaheemMitha - the only thing I sort of don't like is that there can be many .bashrc in the system, and so I cannot use a single absolute path, but I have to resolve via ~/.bashrc (and some programs may choke on ~); but at least every user should have one, and it's good they're non-empty... If nothing else comes along, I'll eventually accept this answer. Cheers!
    – sdaau
    Jan 10, 2014 at 16:04

Most systems also have a dictionary, /usr/share/dict/linux.words

This should give you a list of all text files on your system:

find / -type f -exec file {} + 2>/dev/null| grep ASCII
  • Many thanks for that @Ketan - unfortunately, my Ubuntu 11.04 reports: "ls: cannot access /usr/share/dict/linux.words: No such file or directory"; cheers!
    – sdaau
    Jan 10, 2014 at 16:31
  • 1
    On Ubuntu, you'll probably need to install wordlist package. See: en.wikipedia.org/wiki/Words_(Unix) sudo apt-get install wamerican works on my 12.04 Jan 10, 2014 at 16:40
  • Thanks for that, @Ketan - good to know; but I would have preferred a file that sort of "exists" without installing extra packages... Cheers!
    – sdaau
    Jan 10, 2014 at 16:48
  • I updated my answer with a command that will hopefully help. Jan 10, 2014 at 17:34
  • @sdaau You're likely to have other word lists in /usr/share/dict. But Ubuntu doesn't ship a word list called linux.words. Jan 10, 2014 at 23:21

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