Re: [Python-Dev] hard linking executables
Guido van Rossum wrote: > I ought to remember why because I remember I was involved. (And I have > a feeling that the change Antoine dug up was just a refactoring, You are correct. I checked Python 1.5.2 and it also creates hard links (prior to Makefile overhaul). > The best I can come up with is that when it's a hard link, you can > replace either "python" or "python2.1" with another version without > disturbing the other. So, I don't think anyone has a good argument for the status quo. A symlink would make more sense to me. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hard linking executables
Dan Stromberg writes: > On Wed, Jul 27, 2011 at 2:37 PM, Ben Finney wrote: > > > Dan Stromberg writes: > > > > > It's been suggested that […] if people had added symlinks first, > > > no one would've bothered adding hardlinks. > > > > Well, that suggestion is faulty. It ignores the fact that *all* > > ordinary files on Unix are hard links. Any ordinary file entry in a > > directory is a hard link to the file's data. > > Not really. Whether hard links is supported is mostly a matter of what > filesystem you are using - in modern times. It's true that filesystems > with complete POSIX semantics probably all support hardlinks, but > that's far from every file on any given *ix. And of course, POSIX > doesn't appear to have been created until the late 1990's. POSIX didn't create those semantics, though; it formalised semantics that were already long-time convention. My only point was that, unlike symbolic links, hard linking isn't some added feature, it's a property of the way Unix filesystems represent normal files. And you're right that I mean “on filesystems with POSIX semantics”. > It's much easier to imagine a system with no hardlinks, than to > imagine a system with no symlinks. Why imagine? There have been many of both. -- \“But it is permissible to make a judgment after you have | `\examined the evidence. In some circles it is even encouraged.” | _o__)—Carl Sagan, _The Burden of Skepticism_, 1987 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hard linking executables
On Wed, Jul 27, 2011 at 2:37 PM, Ben Finney wrote: > Dan Stromberg writes: > > > It's been suggested that *ix has hardlinks because someone thought up > > hardlinks before someone thought up symlinks - IOW, there are those who > > suggest that if people had added symlinks first, no one would've bothered > > adding hardlinks. > > Well, that suggestion is faulty. It ignores the fact that *all* ordinary > files on Unix are hard links. Any ordinary file entry in a directory is > a hard link to the file's data. > Not really. Whether hard links is supported is mostly a matter of what filesystem you are using - in modern times. It's true that filesystems with complete POSIX semantics probably all support hardlinks, but that's far from every file on any given *ix. And of course, POSIX doesn't appear to have been created until the late 1990's. > The “hard links” capability, therefore, isn't something that was added; > it's fundamental to Unix filesystems from their inception. > Hard linking was reportedly in Unix Version 1, but I see nothing indicating it was in the original Unics of 1969. Then again, I don't see much of anything on the net about what was and wasn't in Unics. > The ‘ln’ command adds *additional* hard links to an existing file's > data; but, once added, they're exactly the same as any other ordinary > file entry. > Well, if you're in a filesystem that supports hardlinking anyway. Supporting that isn't inherent. It requires some sort of on-disk representation for persistence, and not all filesystems support that. > > Symlinks are almost always more flexible, and almost always more > > clear. > > Yet many tools don't work as expected with symbolic links which will > work with an ordinary file (a “hard link”). One can argue that such > tools are to that extent buggy, but symbolic links produce deliberately > different behaviour which is sometimes not what one needs. > Please recall that I was paraphrasing someone saying that hardlinks were seldom better, not never better. I don't know that there's anything in your post that addresses that. It's much easier to imagine a system with no hardlinks, than to imagine a system with no symlinks. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hard linking executables
Dan Stromberg writes: > It's been suggested that *ix has hardlinks because someone thought up > hardlinks before someone thought up symlinks - IOW, there are those who > suggest that if people had added symlinks first, no one would've bothered > adding hardlinks. Well, that suggestion is faulty. It ignores the fact that *all* ordinary files on Unix are hard links. Any ordinary file entry in a directory is a hard link to the file's data. The “hard links” capability, therefore, isn't something that was added; it's fundamental to Unix filesystems from their inception. The ‘ln’ command adds *additional* hard links to an existing file's data; but, once added, they're exactly the same as any other ordinary file entry. > Symlinks are almost always more flexible, and almost always more > clear. Yet many tools don't work as expected with symbolic links which will work with an ordinary file (a “hard link”). One can argue that such tools are to that extent buggy, but symbolic links produce deliberately different behaviour which is sometimes not what one needs. -- \ “Wrinkles should merely indicate where smiles have been.” —Mark | `\Twain, _Following the Equator_ | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hard linking executables
On Tue, Jul 26, 2011 at 3:32 PM, Barry Warsaw wrote: > On Jul 27, 2011, at 12:19 AM, Antoine Pitrou wrote: > >>Ok, apparently the decision to make hard links for executables dates at >>least back to: > > That still doesn't explain *why* hardlinks were originally chosen instead of > symlinks. In the absence of any other compelling argument against it, I think > they should all consistently be symlinks. I don't see any Ubuntu or Debian > (where /usr/bin/python3 -> python3.2) bug reports indicating any problems, and > I haven't experienced any issues with it personally. I ought to remember why because I remember I was involved. (And I have a feeling that the change Antoine dug up was just a refactoring, moving an existing hard-link target to a different file. Because in my memory the hard link was my idea and I implemented it. But that change is Neil Schemenauer's.) But I can't. :-( The best I can come up with is that when it's a hard link, you can replace either "python" or "python2.1" with another version without disturbing the other. And I think it has something to do with altinstall vs. install. So it would mean that after first installing 2.1 (so python and python2.1 are the same file), and then alt-installing 2.1.1, the original 2.1 binary is still accessible as "python". But I don't know why you'd want that. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hard linking executables
It's been suggested that *ix has hardlinks because someone thought up hardlinks before someone thought up symlinks - IOW, there are those who suggest that if people had added symlinks first, no one would've bothered adding hardlinks. Symlinks are almost always more flexible, and almost always more clear. The main counterexample seems to be rsync-based backup systems, that will hardlink identical files of a given pathname. But that seems to be a bit of a mess when it comes time to transfer such a backup from one filesystem to another. On Tue, Jul 26, 2011 at 3:32 PM, Barry Warsaw wrote: > On Jul 27, 2011, at 12:19 AM, Antoine Pitrou wrote: > > >Ok, apparently the decision to make hard links for executables dates at > >least back to: > > That still doesn't explain *why* hardlinks were originally chosen instead > of > symlinks. In the absence of any other compelling argument against it, I > think > they should all consistently be symlinks. I don't see any Ubuntu or Debian > (where /usr/bin/python3 -> python3.2) bug reports indicating any problems, > and > I haven't experienced any issues with it personally. > > >changeset: 16221:588691f806f4 > >branch: legacy-trunk > >user:Neil Schemenauer > >date:Wed Jan 24 17:11:43 2001 + > >files: Makefile.pre.in > >description: > >Flat makefile based on toplevel Makefile.in and makefiles in build > >subdirectories. Those other makefiles will go away eventually. > > > >[...] > > > >+# Install the interpreter (by creating a hard link to python$(VERSION)) > >+bininstall:altbininstall > >+ -if test -f $(BINDIR)/$(PYTHON); \ > >+ then rm -f $(BINDIR)/$(PYTHON); \ > >+ else true; \ > >+ fi > >+ (cd $(BINDIR); $(LN) python$(VERSION)$(EXEEXT) python$(EXEEXT)) > >+ > > -Barry > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/drsalists%40gmail.com > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hard linking executables
On Jul 27, 2011, at 12:19 AM, Antoine Pitrou wrote: >Ok, apparently the decision to make hard links for executables dates at >least back to: That still doesn't explain *why* hardlinks were originally chosen instead of symlinks. In the absence of any other compelling argument against it, I think they should all consistently be symlinks. I don't see any Ubuntu or Debian (where /usr/bin/python3 -> python3.2) bug reports indicating any problems, and I haven't experienced any issues with it personally. >changeset: 16221:588691f806f4 >branch: legacy-trunk >user:Neil Schemenauer >date:Wed Jan 24 17:11:43 2001 + >files: Makefile.pre.in >description: >Flat makefile based on toplevel Makefile.in and makefiles in build >subdirectories. Those other makefiles will go away eventually. > >[...] > >+# Install the interpreter (by creating a hard link to python$(VERSION)) >+bininstall:altbininstall >+ -if test -f $(BINDIR)/$(PYTHON); \ >+ then rm -f $(BINDIR)/$(PYTHON); \ >+ else true; \ >+ fi >+ (cd $(BINDIR); $(LN) python$(VERSION)$(EXEEXT) python$(EXEEXT)) >+ -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] hard linking executables
Ok, apparently the decision to make hard links for executables dates at least back to: changeset: 16221:588691f806f4 branch: legacy-trunk user:Neil Schemenauer date:Wed Jan 24 17:11:43 2001 + files: Makefile.pre.in description: Flat makefile based on toplevel Makefile.in and makefiles in build subdirectories. Those other makefiles will go away eventually. [...] +# Install the interpreter (by creating a hard link to python$(VERSION)) +bininstall:altbininstall + -if test -f $(BINDIR)/$(PYTHON); \ + then rm -f $(BINDIR)/$(PYTHON); \ + else true; \ + fi + (cd $(BINDIR); $(LN) python$(VERSION)$(EXEEXT) python$(EXEEXT)) + Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
