4 ms·
It's swings and roundabouts. Say I create an app or tool that happily resides in c:\proc\whatever then I turn my attention to creating a Linux version and speci
by teh_klev 9y ago
It's swings and roundabouts. Say I create an app or tool that happily resides in c:\proc\whatever then I turn my attention to creating a Linux version and specify /proc/whatever then ... boom? Sure, it's maybe a convoluted example, but for the creator of this "nul" package they got burned by something that's actually common knowledge in the MS world.
I think you need to be a wee bit pro-active and take a look at your potential deployment targets and try and guard against these types of naming issues. Unix and Linux aren't the only (one true) operating systems in the world.
- majewsky 9y agoThe right solution, actually, is to use a library that gives you the right path for the thing that you need to do depending on the conventions of the platform. For example QStandardPaths in Qt: http://doc.qt.io/qt-5/qstandardpaths.html http://doc.qt.io/qt-5/qstandardpaths.html QString appDataDir = QStandardPaths::writableLocation(QStandardPaths::AppDataLocation); // ~/Library/Application Support/<APPNAME> on macOS // C:/Users/<USER>/AppData/Roaming/<APPNAME> on Windows // ~/.local/share/<APPNAME> on Linux
- teh_klev 9y agoStill doesn't solve the case where the developer just wants to slap something in the root of the C: drive on windows from the outset (Cygwin I seem to remember defaults to c:\Cygwin for example...again slightly convoluted). Also those locations are user specific, there's nothing there to support the use-case of an app that's available to all users, or might just be a system service (/daemon).