Please stop using environment path for software.

Discussion in 'C Programming' started by Skybuck Flying, Jun 11, 2014.

  1. Hello,

    The environment path on my Windows computer is completely full.

    It's so full that it might have even pushed out window's paths.

    My windows (gui) is starting to malfunction.

    It can no longer find windows explorer via taskbar and it can no longer find
    calculator via the start menu.

    Either Microsoft increase environment path length.

    Or software developers stop using it !

    Thank you and have a nice day !

    (Windows 7 Ultimate)

    Skybuck Flying, Jun 11, 2014
    1. Advertisements

  2. Skybuck Flying

    David Brown Guest

    Why don't you just edit the path variable to remove the cruft?

    Alternatively, you could try using a /real/ operating system and avoid
    the problem altogether (i.e., one in which programs are installed in
    sensible places, the environment variable system and paths work well,
    and software installation doesn't mess with them).
    David Brown, Jun 11, 2014
    1. Advertisements

  3. Skybuck Flying

    BartC Guest

    I assume you mean a real OS where all the files associated with a particular
    app are disseminated throughout the file system, and rub shoulders with
    similar files of every other application?

    Compared with Windows where such files are tidily stored all in one place
    (which means that updates, backups, copies, alternate versions, searches
    through the files etc trivial operations).

    (And a real OS which likes to keep users on their toes by not giving
    executables, for example, a special extension such as .exe, but makes the
    filename look like any other filename! Just to make searching for a
    particular app a bit more challenging. At least, until you establish that no
    executable of interest in actually in /bin, but a random search through
    other top-level directories eventually shows that they are all hiding in
    /usr/bin. So that's the main executable; but where are the 2000 other files
    it needs?)
    BartC, Jun 11, 2014
  4. Skybuck Flying

    David Brown Guest

    Because the programs themselves in Linux are all placed in one of a very
    few directories, they are all accessible conveniently from a short and
    simple PATH - solving exactly the problem that Skybuck has here.

    Everything else you mention is just a repeat of moans you have made on
    previous occasions about how you dislike the Linux filesystem standards.

    I use both Windows and Linux, and they each have their advantages and
    disadvantages - but I greatly prefer the standard filesystem layout of

    Linux is nothing if not flexible, however. For a completely different
    arrangement that might suit your preferences more, see
    Windows programs are /not/ stored tidily. Most of the main code and
    data files for a program gets put (by default) into idiotically long
    directory paths. Other parts get put into the windows directory, the
    system directory, user directories (often under long and hidden paths),
    and sometimes with older programs in newer windows you get settings
    files that /pretend/ to be in the program directory, but are actually in
    another hidden user directory.

    I don't disagree that program installations are split up in a Linux
    system - typically you have the program itself in /usr/bin, data files
    in /usr/share/<program>/, system-wide configuration in /etc and user
    configuration in /home/<user/. I just disagree that this is
    "disseminated throughout the file system", and I disagree that the
    Windows way is any clearer or more logical. It's just different.
    There are historical reasons for the split between /bin and /usr/bin,
    with good reasons based on the flexibility of Linux (and other *nix)
    regarding filesystems and mounts - something that is simply unknown in
    the Windows world. Simple, important, and low-level programs are
    usually in /bin while "applications" and less necessary programs go in
    /usr/bin. It's not that hard.

    A /real/ OS does not trust file names in order to decide what to do with
    files. Anyone who has ever run malware with a name such as
    "Readme.txt.exe" knows that. A /real/ OS checks what a file actually
    /is/ before deciding how to "open" it. And filemanagers and command
    line directory listings can show the difference between programs and
    files, rather than - as window programs often do - using identical icons
    for both programs and datafiles.

    And as for finding the other files needed for a particular program, why
    do you actually /care/ where they are? When I start a program in Linux,
    the /program/ knows where all other necessary files are kept. If I want
    to uninstall the program, the package manager knows all about it.
    David Brown, Jun 11, 2014
  5. Skybuck Flying

    BartC Guest

    (I don't recall any recent posts like that, not about the difficulty of
    finding your way around the file system anyway. There was one related post
    in c.u.p I made on 11.Jul.2013 but that was a question not a criticism.)
    (That makes exactly the same point I do!)
    (Some complex apps, yes, unless you override. But everything needed for
    gcc/Mingw is in \mingw, everything for PellesC is in \pec (you choose the
    top-level path name), for lcc in \lcc64, for dmc in \dmc, for gcc/TDM in
    \tdm, for Clang in \clang (and for Python in \python2x etc) ... you get the

    And they can all have an utility called make.exe for example, which would
    cause some problems if there were half-a-dozen executables called 'make' in

    BTW what happens when you want to run a program, say a C compiler, from a
    self-contained directory on a USB drive?)
    BartC, Jun 11, 2014
  6. Skybuck Flying

    David Brown Guest

    I remember such a post, but I could be mistaken or misattributing it. A
    lot of posts pass through this group - if I've got it wrong, then I
    apologise of course.
    Indeed it does - you are not alone in your ideas here. And while I
    don't see the Linux standard filesystem layout as being a problem, I can
    see some advantages of the GoboLinux ideas. I posted the link because I
    thought you might find it interesting.
    Yes, you can override the base installation paths for most programs (and
    I do so usually), though some bits get forced into specific places.

    (One point to note here is that on Linux systems, when you have
    third-party software that is not handled by your package manager, the
    software is usually installed in a single directory under /opt or
    /usr/local - just like you describe for third-party software on Windows.)
    What makes this all work is that the unix philosophy is different from
    the windows philosophy. If you have a dozen different C compilers for
    Linux (and I do - for different target architectures), these are C
    compilers. They do not have their own "make" utility - they all share
    the standard "make". Thus /usr/bin can have a single "make" that suits
    all. With the Windows way, each of these compilers has its own
    incompatible make, none of which can be easily accessed from a command
    line. Putting each make.exe in its own program directory avoids the
    conflicts, but it also avoids the convenience of standard utilities that
    are directly accessible and shared by anyone and any program that needs

    (The way I handle this on Windows is to install msys and put it on the
    system path, and use standard make and Makefiles rather than anything
    that comes with a particular compiler or tool.)
    Mount the drive somewhere, as usual (this is often done automatically
    when you insert it, but that's up to your distribution and any changes
    you have made to the automounting setup). Then run the program.

    For example, I have Freescale's CodeWarrior installed on my Linux system
    in a self-contained directory. I run it with:


    (Actually, I run it with "cwide" as I've made a symbolic link in my
    ~/bin directory.)

    I can also run the compiler and other tools directly from their paths.
    David Brown, Jun 12, 2014
  7. Skybuck Flying

    Jorgen Grahn Guest

    ["Followup-To:" header set to comp.lang.c.]

    To be fair, that works because programmers respect the rules for
    packaging. Pick some older or weirder piece of Unix software, and the
    environment situation may be just as bad as for older/weirder software
    on Windows.

    A program should be immediately usable when it's installed. Users
    should not have to hack their init scripts to use it.
    Partly because of your complaint #1, we don't need the suffix in your
    complaint #2. Not that I see why you'd want to search the file system
    -- if foobar is installed then it's in your path and 'which foobar'
    will tell you where the executable is if you really need to know.
    If you need to know that on Linux, you use the package manager
    (rpm, dpkg, ...) to list the files.

    Jorgen Grahn, Jun 14, 2014
  8. Skybuck Flying

    BartC Guest

    In that case why do we need file extensions at all?
    BartC, Jun 14, 2014
  9. Skybuck Flying

    Richard Bos Guest


    File extensions are actually a massive security hole in Windows.

    Richard Bos, Jun 14, 2014
  10. We don't - there simply are no "file extensions" under Unix.
    Anything like ".jpg" or ".c" or whatever else is at the end
    is simply a part of the file name which may help humans to
    recognize the file type more easily (the 'file' utility usu-
    ally does a more reliable job of determing file types since
    it isn't fooled by someone having modified the extension).
    It's only a few applications that assign some special meaning
    to these parts of file names (like, for example, gcc, that
    tries to compile a file with a name ending in ".c" in C mode
    while, for files ending in ".cxx" etc., it switches to C++
    mode). But the system doesn't care at all about them: if I
    rename an executable 'a' to 'a.c' I still can run it as long
    as I didn't mess around with the execute flags. And many appli-
    catons also don't care about "extensions".

    Finding only executable files (and searchable directories since
    they also have the execute flag set) isn't hard, just pass the
    '-executable' option to 'find'. Add '-type f' and it will only
    list executable files.
    Regards, Jens
    Jens Thoms Toerring, Jun 14, 2014
  11. Hiding the extensions is a disaster. So too is providing an
    automatic "open" without also an accessible "open with" which
    allows any program to be specified.
    But the extension idea itself has worked well. The format of
    the file is recognisable from the name. You can always have a
    corrupt file, so extension hacking shouldn't be a problem.
    Malcolm McLean, Jun 14, 2014
  12. [SNIP]

    Why? I didn't see anything about C in your post.
    Keith Thompson, Jun 14, 2014
  13. Skybuck Flying

    BartC Guest

    Extensions are tremendously useful. And for binary formats there will be
    further checks that a file is actually of the right kind.

    What I don't like is being told by an OS advocate that I can't do something
    because there is no need to do it, or I can't find out something because
    there is no need for me to know.

    I'd rather have those choices however. I'm not a consumer running some app
    that is expected to work; frequently things don't work and I need to
    investigate why not.
    BartC, Jun 14, 2014
  14. Skybuck Flying

    Jorgen Grahn Guest

    Because I wanted to reply, didn't want to encourage more cross-posting
    to the Delphi group, and the people I wanted to respond to were known
    comp.lang.c regulars. I agree it's not a perfect solution.

    Jorgen Grahn, Jun 15, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.