Mailing List Archive

Changing 'Scripts/*.exe'
Hello list.

I'm moved my old Python27 installation from
f:\ProgramFiler\Python27 ( == 'ProgramFiles')
to
f:\gv\Python27

and now many 'scripts/*.exe' program fails
to start since the old path to 'Python.exe'
is wrong.

E.g. 'Scripts/pip2.exe' has the path
"f:\programfiler\python27\python.exe" hard-coded
inside it.

Is there a easy way to fix this w/o re-installing this
old Python?

--
--gv
--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
On 02/10/2022 04.50, Gisle Vanem via Python-list wrote:
> Hello list.
>
> I'm moved my old Python27 installation from
>   f:\ProgramFiler\Python27  ( == 'ProgramFiles')
> to
>   f:\gv\Python27
>
> and now many 'scripts/*.exe' program fails
> to start since the old path to 'Python.exe'
> is wrong.
>
> E.g. 'Scripts/pip2.exe' has the path
> "f:\programfiler\python27\python.exe" hard-coded
> inside it.
>
> Is there a easy way to fix this w/o re-installing this
> old Python?

Yes, by putting a symbolic-link at the old 'programfiler' location which
points to the new 'gv' installation.

Regret that not using MS-Windows, can't give exact instruction. Please
review:

Symbolic link: https://www.computerhope.com/jargon/s/symblink.htm
Symbolic Links:
https://learn.microsoft.com/en-us/windows/win32/fileio/symbolic-links

--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
Gisle Vanem <gvanem@yahoo.no> writes:

> Hello list.
>
> I'm moved my old Python27 installation from
> f:\ProgramFiler\Python27 ( == 'ProgramFiles')
> to
> f:\gv\Python27
>
> and now many 'scripts/*.exe' program fails
> to start since the old path to 'Python.exe'
> is wrong.
>
> E.g. 'Scripts/pip2.exe' has the path
> "f:\programfiler\python27\python.exe" hard-coded
> inside it.
>
> Is there a easy way to fix this w/o re-installing this
> old Python?

Wouldn't it be great if it were portable by default?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
dn wrote:

>> E.g. 'Scripts/pip2.exe' has the path
>> "f:\programfiler\python27\python.exe" hard-coded
>> inside it.
>>
>> Is there a easy way to fix this w/o re-installing this
>> old Python?
>
> Yes, by putting a symbolic-link at the old 'programfiler' location which
> points to the new 'gv' installation.

I'm suspicious about sym-links.

Instead for 'pip' I just did a 'py -2 get-ip.py' which seems
to have fixed it. The newly generated 'f:\gv\Python27\Scripts\pip2.exe'
seems to work fine; the list from 'pip2.7.exe list' is correct.

--
--gv

--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
On 03/10/2022 20.48, Gisle Vanem via Python-list wrote:
> dn wrote:
>
>>> E.g. 'Scripts/pip2.exe' has the path
>>> "f:\programfiler\python27\python.exe" hard-coded
>>> inside it.
>>>
>>> Is there a easy way to fix this w/o re-installing this
>>> old Python?
>>
>> Yes, by putting a symbolic-link at the old 'programfiler' location which
>> points to the new 'gv' installation.
>
> I'm suspicious about sym-links.

OT: I'm sufficiently intrigued to ask "why?" - or are you only talking
of the MS-Windows implementation?


> Instead for 'pip' I just did a 'py -2 get-ip.py' which seems
> to have fixed it. The newly generated 'f:\gv\Python27\Scripts\pip2.exe'
> seems to work fine; the list from 'pip2.7.exe list' is correct.

As long as things are working again, we're all happy!
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
> On 1 Oct 2022, at 16:50, Gisle Vanem via Python-list <python-list@python.org> wrote:
>
> Hello list.
>
> I'm moved my old Python27 installation from
> f:\ProgramFiler\Python27 ( == 'ProgramFiles')
> to
> f:\gv\Python27

The design of Windows installed software makes this hard to do without a lot of knowledge about what the installation did.

For example there are registry keys that hold information on where python 2.7 is installed and there is other software that
will read the registry and expect that information to be correct.

I would have backed the old installation, uninstalled and the reinstalled python where you want it to be.

>
> and now many 'scripts/*.exe' program fails
> to start since the old path to 'Python.exe'
> is wrong.
>
> E.g. 'Scripts/pip2.exe' has the path
> "f:\programfiler\python27\python.exe" hard-coded
> inside it.
>
> Is there a easy way to fix this w/o re-installing this
> old Python?

The advice you have had will get you someway to fixing the breakage.
But do not be surprised if more things break as you try different things out.

As I say I would have backed up the files, uninstall and reinstall then put back from backup
any files that are not installable anymore.

Why did you move the files from where they where installed and working?

Barry


>
> --
> --gv
> --
> https://mail.python.org/mailman/listinfo/python-list
>

--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>>Wouldn't it be great if it were portable by default?
>
> I think under Windows there is a division of software
> suggested by Microsoft, a division of software into
> executable code and data (data may change in time).
>
> The executable code is supposed to rest under
> "C:\Program Files" the contents of which cannot be
> modified by user processes easily. Program configuration
> can be stored below "AppData" in the user directory.
> It is supposed to be more secure when executable code
> cannot be modified easily by user processes.
>
> So far, Python has decided to ignore this and install
> everything under AppData as I understand it. So one
> gets neither the security of "Program Files" nor the
> possibility to move it to another directory easily.

Interesting. I like portable things. You copy from one place to
another and it just runs. As it should. Things should be simple.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
On 04/10/2022 14.10, Meredith Montgomery wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>> Wouldn't it be great if it were portable by default?
>>
>> I think under Windows there is a division of software
>> suggested by Microsoft, a division of software into
>> executable code and data (data may change in time).
>>
>> The executable code is supposed to rest under
>> "C:\Program Files" the contents of which cannot be
>> modified by user processes easily. Program configuration
>> can be stored below "AppData" in the user directory.
>> It is supposed to be more secure when executable code
>> cannot be modified easily by user processes.
>>
>> So far, Python has decided to ignore this and install
>> everything under AppData as I understand it. So one
>> gets neither the security of "Program Files" nor the
>> possibility to move it to another directory easily.
>
> Interesting. I like portable things. You copy from one place to

At which point we mention that this is exactly how Linux works. A 'zen'
of Linux applications and utilities has always been: "do one thing, and
do it well".

Then directory/file access controls aim to keep users in 'userland' and
away from 'system', and for folk who want more there are security
features such as apparmor which limit the types of usage of files (as
well as resisting external threats).

Extending this a little further: such philosophy enables Linux users to
more-easily install (and run) multiple versions of Python*, Firefox,
Chromium, etc, without resorting to containers or VMs.

* eg v2 and v3 installed concurrently, to possibly suit OP

> another and it just runs. As it should. Things should be simple.

+1
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
On 2022-10-04 at 14:55:36 +1300,
dn <PythonList@DancesWithMice.info> wrote:

> On 04/10/2022 14.10, Meredith Montgomery wrote:
> > ram@zedat.fu-berlin.de (Stefan Ram) writes:
> >
> >> Meredith Montgomery <mmontgomery@levado.to> writes:
> >>> Wouldn't it be great if it were portable by default?
> >>
> >> I think under Windows there is a division of software
> >> suggested by Microsoft, a division of software into
> >> executable code and data (data may change in time).
> >>
> >> The executable code is supposed to rest under
> >> "C:\Program Files" the contents of which cannot be
> >> modified by user processes easily. Program configuration
> >> can be stored below "AppData" in the user directory.
> >> It is supposed to be more secure when executable code
> >> cannot be modified easily by user processes.
> >>
> >> So far, Python has decided to ignore this and install
> >> everything under AppData as I understand it. So one
> >> gets neither the security of "Program Files" nor the
> >> possibility to move it to another directory easily.
> >
> > Interesting. I like portable things. You copy from one place to
^
Copy what? That's the crux of it.

On vintage (1980s? 1990s? way before OS X, anyway) Mac OS, I could copy
an alias (Mac's version of a symbolic link) to a floppy disk, walk (IOW,
"transfer via sneaker net") that alias to another Mac on the network,
and open *the original file* from that other Mac. (I could even move
the file to another folder on the original Mac, but that didn't mean
much, because those old file systems were entirely flat (directories and
folders were an illusion maintained by the Finder).)

Permissions? We don't need no stinkin' permissions! ;-)

> > another and it just runs. As it should. Things should be simple.
>
> +1

I like simple, portable things, too. But this kind of simplicity
(applications looking in known locations for certain files) and this
kind of portability (allowing users to move those files) are at oods.
And that's before we consider security.

Also, [almost] by definition, Python virtual environments really blur
the lines between user, system, public, private, programs, and data.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Changing 'Scripts/*.exe' [ In reply to ]
On 4/10/22 10:49 pm, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
> (I could even move
> the file to another folder on the original Mac, but that didn't mean
> much, because those old file systems were entirely flat (directories and
> folders were an illusion maintained by the Finder)

That was only true in the very early days. A proper hierarchical
file system was available as soon as hard disks became common
(around the Mac II era I think?)

However, internally each file on a volume was identified by a
File ID (something a bit like an inode number) and that was
stored in the alias and used as the first means of finding the
file. There was also a pathname stored in the alias, but that
was only used as a backup in case the file couldn't be found
using the File ID.

So a Mac alias was in some ways more powerful than a
symlink, but in other ways less -- e.g. there was no equivalent
to a relative symlink. Also aliases are more like a Windows
shortcut in that they aren't resolved automatically in the
kernel -- programs need to be aware of them and take explicit
action to resolve them.

Things are even more confusing in MacOSX, which has both
aliases *and* symlinks, they behave differently, and the Finder
doesn't tell you which you're looking at. :-(

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list