Please stop using environment path for software.


S

Skybuck Flying

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)

Bye,
Skybuck.
 
Ad

Advertisements

D

David Brown

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)

Bye,
Skybuck.

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).
 
B

BartC

David Brown said:
On 11/06/14 01:48, Skybuck Flying wrote:
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).

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?)
 
D

David Brown

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?

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.

Linux is nothing if not flexible, however. For a completely different
arrangement that might suit your preferences more, see
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).

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.
(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?)

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.
 
B

BartC

David Brown said:
....
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 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.)
I use both Windows and Linux, and they each have their advantages and
disadvantages - but I greatly prefer the standard filesystem layout of
Linux.

Linux is nothing if not flexible, however. For a completely different
arrangement that might suit your preferences more, see
<http://www.gobolinux.org/?page=at_a_glance>

(That makes exactly the same point I do!)
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.

(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
idea.

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
/usr/bin.

BTW what happens when you want to run a program, say a C compiler, from a
self-contained directory on a USB drive?)
 
D

David Brown

(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.)

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.
(That makes exactly the same point I do!)

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.
(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
idea.

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.)
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
/usr/bin.

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
them.

(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.)
BTW what happens when you want to run a program, say a C compiler, from a
self-contained directory on a USB drive?)

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:

/usr/local/Freescale/CodeWarrior_MCU_10.2/eclipse/cwide

(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.
 
Ad

Advertisements

J

Jorgen Grahn

["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.
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.

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.
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?)

If you need to know that on Linux, you use the package manager
(rpm, dpkg, ...) to list the files.

/Jorgen
 
B

BartC

Jorgen Grahn said:
["Followup-To:" header set to comp.lang.c.]
(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.

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

In that case why do we need file extensions at all?
 
R

Richard Bos

BartC said:
Jorgen Grahn said:
["Followup-To:" header set to comp.lang.c.]
(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.

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

In that case why do we need file extensions at all?

_Exactly_.

File extensions are actually a massive security hole in Windows.

Richard
 
J

Jens Thoms Toerring

BartC said:
Jorgen Grahn said:
["Followup-To:" header set to comp.lang.c.]
(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.

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
In that case why do we need file extensions at all?

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
 
M

Malcolm McLean

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).
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.
 
Ad

Advertisements

B

BartC

Malcolm McLean said:
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.

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.
 
Ad

Advertisements

J

Jorgen Grahn

Jorgen Grahn said:
["Followup-To:" header set to comp.lang.c.]
[SNIP]

Why? I didn't see anything about C in your post.

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
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Top