29

My company resells an application whose brand name is mixed case, for example "ApplicationName".

The application's installer creates all paths and file names in this standard. E.g. The main directory is /opt/ApplicationName, the init file is called ApplicationName so I have to run service ApplicationName status and so on.

To me, this breaks all sensible conventions and I feel the files and directories should all be lower case (there is precedent in other applications such as MySQL, whose files and dirs are all called mysql, even applications like Apache and Tomcat do away with the preceding upper case letter).

If I raise this as a bug report, I'd like to put up a stronger argument than just "I think it's wrong". So is it dictated in something like the POSIX standard that system files like this should be lower case?

Darren
  • 449
  • 9
    You can also point out that it is exceedingly annoying for your customers since you'll be forcing them to use an extra button (shift). This may not seem like a big deal (OK, it isn't) but it is annoying. – terdon Apr 10 '17 at 10:00
  • @terdon, Thanks for the input and it's generally a good point, but we tend to manage the application ourselves on behalf of our customers so they won't encounter this under normal circumstances. – Darren Apr 10 '17 at 10:02
  • 5
    Some filesystems are case insensitive, it would be worth pointing out a simple typo (eg, some user script referencing the file at "applicationname" by mistake) would work on some systems but not on others, the issue would not be picked up immediately and could be costly to find later. A more explicit "application_name" is less likely to have this issue. – Stefan Apr 10 '17 at 10:25
  • There is less chance of an uppercare "i" getting in to confuse with a lowercase "L" if the character subset is confined to just one case. – KalleMP Apr 10 '17 at 11:28
  • 11
    Another counterexample: anything related to X11 usually has a capital X in its filename, e.g. /usr/X11R6, /usr/lib/libX11.so, and so on. – nomadictype Apr 10 '17 at 12:10
  • 1
    X would like to be your trend-proving exception today. – Weaver Apr 10 '17 at 12:11
  • 1
    @nomadictype Apart from running on a Unix system, the X Windows System has very little to do with the Unix POSIX standard. – Kusalananda Apr 10 '17 at 14:37
  • @terdon I keep case-insensitive autocomplete on for that reason (the edge case of two files/dirs with the same name but different capitalization has been very infrequent, from my experience). – JAB Apr 10 '17 at 20:46

3 Answers3

44

No, lower case names are not specified for software package installation directories.

In fact, historically software packages installed in /opt started with the all-capitals stock ticker symbol of the company providing the package, such as SUNW for Sun Microsystems or ORCL for Oracle.

So packages such as Sun's QFS filesystem would be installed in a directory named something like /opt/SUNWqfs.

Andrew Henle
  • 3,780
  • 7
    TIL this new titbit about stock tickers. Upvoted. Thanks. – Darren Apr 10 '17 at 10:19
  • 2
    I believe that convention only applied to SunOS/Solaris. – fpmurphy Apr 10 '17 at 10:35
  • 3
    @fpmurphy1 Perhaps. But given how Sun treated POSIX compliance, I doubt the naming scheme they chose would violate any part of the standard. Nor would I think Sun would have had much success in convincing Oracle to use any naming scheme. – Andrew Henle Apr 10 '17 at 10:38
  • 1
    @AndrewHenle, SMIs naming scheme for SunOS/Solaris conformed to the relevant standards and specifications. Both POSIX and Single Unix Specification define shouldto be essentially it is recommended – fpmurphy Apr 10 '17 at 10:59
  • upper case names just feel gritty and adopted-from-a-mainframe :) – rackandboneman Apr 11 '17 at 08:53
27

The POSIX standard has a section with guidelines for conforming utilities (i.e., "such as those written specific to a local system or that are components of a larger application") that says

  1. Utility names should be between two and nine characters, inclusive.
  2. Utility names should include lowercase letters (the lower character classification) and digits only from the portable character set.

[ref: 12.2 Utility Syntax Guidelines]

It's unclear to me whether the use of the words "should include" really means "should only include". (The consensus in the comments below is that it means "should only include").

An application on a Unix system that does not claim to be a POSIX conformant utility may otherwise use whatever name it wants. If it does claim to be a POSIX conformant utility that is part of the POSIX shell utilities, the text after the guidelines in section 12.2 says that "should" changes meaning to "shall".

There are no similar guideline regarding directory names as far as I know. macOS (which is a certified UNIX 03 product when running on an Intel-based Mac computer) uses /Users as the prefix for user's home directories, for example, as well as a number of other mixed-case directory names.

Kusalananda
  • 333,661
  • 3
    I don't think they actually claim to be POSIX compliant anywhere. Interestingly, the application name is 10 characters long so they fail on that front too. BTW, the way I read point 2 is "it should only include lower case and digits - I think the final "only" covers the entire clause. Maybe a question for english.stackexchange.com :) – Darren Apr 10 '17 at 10:22
  • @Darren Yes, you might be right. There might be an "invisible" comma before "from" (or "only"). – Kusalananda Apr 10 '17 at 10:30
  • 3
    XBD defines should as follows:

    "For an implementation that conforms to IEEE Std 1003.1-XXXX, describes a feature or behavior that is recommended but not mandatory. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations.

    For an application, describes a feature or behavior that is recommended programming practice for optimum portability."

     – fpmurphy Apr 10 '17 at 10:37
  • 5
    Does the naming of an application have anything to do with the naming of system utilities? – Matti Virkkunen Apr 10 '17 at 11:48
  • Note that the "should"->"shall" reinterpretation in the guidelines you linked to applies only to "utilities [described in] in the Shell and Utilities volume of POSIX.1-2008". Even if the OP's application claimed POSIX compliance, it still (presumably) wouldn't actually be one of the utilities described in the POSIX standard. – Ilmari Karonen Apr 10 '17 at 16:20
  • 1
    @IlmariKaronen Correct. The guidelines are for implementing the utilities described in the standard itself. – Kusalananda Apr 10 '17 at 17:16
  • 3
    There is an "only" in the sentence you quoted. It comes at an awkward point in the phrase, probably due to committee editing, but it still has the same effect. – hobbs Apr 10 '17 at 20:25
  • @IlmariKaronen I have re-read the section in the standard and provided a more nuanced answer. – Kusalananda Apr 11 '17 at 08:31
  • @MattiVirkkunen After a re-read of the standard I noticed that the guidelines do apply to utilities "written specific to a local system or that are components of a larger application". It is still unclear what the difference between an "application" and a "utility" really is. On one hand it defines "utility" as a POSIX shell utility, on the other, it refers to utilities developed for a local system, as part of an application. – Kusalananda Apr 11 '17 at 08:35
4

Beside POSIX guidelines said, I think that could have even more weight the user tradition. Case names as "ApplicationName" became popular with Wikis explosion, accustoming some people (like me) to use capitals instead of hyphens, or worse, spaces. But this was some years after Linux and similar OS become popular, with a very long Unix tradition behind.

This tradition has been (is) always the simplicity, not only to follow the rules that Kusalananda pointed, even abbreviating words of four-six characters only (e.g., /usr for "user", or /srv for "serve" or /mntfor "mounted") and obviously longer meanings (/sbin for "superuser binaries". In this tradition, uppercase, force you to press the Shift key, and maybe accidentally also the Caps Lock key, is simply evil.

At some extent, this is astonishing because Unixes has been for long time able to write case sensitive long filenames, while in contrast, MS-DOS/Windows was limited to case insensitive short filenames (eight characters plus three for the extension) but quickly lost this simplicity ("Program Files","My Documents", etc.) when Windows 95 surpass this limitation.

Nonetheless, today there are a few exceptions like the NetworkManager daemon and probably we will see more WikiWords in the future. But we still hate the mouse and write in the terminal long names that you can end only with the TabTab autocompletion. Or someone see some advantage renaming vim to VisualImproved?

Fran
  • 1,811
  • 3
    /usr is not shorthand for "user". It is shorthand for "Unix system resource" – fpmurphy Apr 12 '17 at 03:13
  • 1
    @fpmurphy1 that smells like a backronym. – hobbs Apr 12 '17 at 06:09
  • 3
    @fpmurphy1 /usr originally was the directory to contain user's home directories (like /home today) . I agree with hobbs. – Fran Apr 12 '17 at 07:25
  • 2
    In Windows, My Computer isn't, and has never been, a directory. It is purely a shell construct; you can illustrate this by considering how you would, in a command prompt or in an old-style Win16 application, navigate to it. Program Files is a mess all of its own, with its localized name; I ran into that issue most recently literally yesterday, where a piece of software assumed the English name of Program Files but the actual name as used was localized on the system. Probably one of Microsoft's worse goofs in Windows 95. – user Apr 12 '17 at 09:09
  • @hobbs. @Fran Just do an Internet for /usr and Unix System Resources And, yes, in early versions of Unix, users home directories also lived under `/usr' – fpmurphy Apr 13 '17 at 02:00
  • @fpmurphy1 I do get a few that do say that's a backronym: http://askubuntu.com/a/135679/158442, http://unix.stackexchange.com/a/103348/70524, http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html, and this SF post's claim that /usr does stand for Unix System Resources is not backed up by any sources. Not only that, "Unix System Resources" doesn't even show up in ngrams! – muru Apr 13 '17 at 03:08
  • It is either a backronym or a retronym. – fpmurphy Apr 13 '17 at 16:41