public inbox for
 help / color / mirror / Atom feed
From: "Hans-Bernhard Bröker" <>
Subject: Re: How to handle length limit of PATH environment variable
Date: Fri, 06 Apr 2018 00:31:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Am 05.04.2018 um 11:19 schrieb Peter Bauer:

> i was bitten by the length limit of the PATH variable of 4095 characters 
> (see [1]) and could not find a way around it. This means i have a lot of 
> software packages in different directories and each of them adds itself 
> to the PATH so one can run the executables and have the shared libs 
> available. 

As far as DLLs are concerned, that would be a misuse of the PATH.  AFAIK 
they will already be found by being in the same directory as the 
executable that needs them.

> Under Windows there is the "short path workaround" but what 
> to do under Cygwin?

Being Cygwin, you should do what Unix has always done: do away with the 
whole idea that every program needs an entire directory tree of its own. 
  The promise that this would somehow make separate installation and, 
more importantly, un-installation or update of program packages much 
easier was never really kept, anyway.

I.e. you shoule have _one_ tree like thone below /usr, instead of dozens 
of c:/programs/manufacturer/package trees.  And while maintaining such a 
collection on Windows might seem nightmarish, tools like "stow" make it 
quite manageable on a Unix-style platform, with Unix-style software 
packages.  With stow, it works like this for a typical autoconf'ed package:

	.../configure --prefix=somewhere
	make install prefix=somewhere/.stow/packagename
	pushd somewhere/.stow/
	stow packagename

Stow then builds and maintains a thicket of symlinks from "somewhere" 
into the individual packages' trees under "somewhere/.stow" such that 
the packages work just as if they had actually been installed directly 
into "somewhere", while they're still separate and can be updated or 
uninstalled individually.  Sometimes package have to be massaged bit 
(e.g. for GNU info 'dir' files), but it works remarkably well given how 
simple it is, at heart.

Problem reports:
Unsubscribe info:

      parent reply	other threads:[~2018-04-06  0:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05  9:19 Peter Bauer
2018-04-05 10:06 ` Wolf Geldmacher
2018-04-05 16:26   ` Brian Inglis
2018-04-05 11:50 ` Steven Penny
2018-04-05 17:50 ` Andrey Repin
2018-04-05 18:48   ` Achim Gratz
2018-04-06  0:35     ` Andrey Repin
2018-04-11 13:43     ` Peter Bauer
2018-04-06  0:31 ` Hans-Bernhard Bröker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).