/usr/local/bin/perl

/usr/local/bin/perl

[Adam Spiers]

This must have come up before, but I can't see it in the archives.

The following scripts hardcode binary locations (excluding /bin/sh
since if a system can't cope with that ...) :

   Functions/Misc/run-help  :   #!/usr/local/bin/zsh
   Functions/Misc/zless     :   #!/usr/bin/zsh -f
   Misc/bash2zshprompt      :   #!/usr/bin/perl -w
   Misc/globtests           :   #!/usr/local/bin/zsh -f
   Misc/globtests.ksh       :   #!/usr/local/bin/zsh -f
   Misc/lete2ctl            :   #!/usr/local/bin/perl -w
   Misc/make-zsh-urls       :   #!/usr/bin/perl -w
   Test/ztst.zsh            :   #!/usr/local/bin/zsh -f
   Util/helpfiles           :   #!/usr/bin/perl -- -*-perl-*-
   Util/reporter            :   #!/usr/local/bin/zsh
   Util/helpfiles           :   #!/usr/local/bin/perl -- -*-perl-*-

Can we avoid this?  Is env(1) common to enough platforms, for
instance, or maybe we could add something to configure?

Re: /usr/local/bin/perl

[Oliver Kiddle]

--- Adam Spiers <adam@spiers.net> wrote: > 
> The following scripts hardcode binary locations (excluding /bin/sh

> Can we avoid this?  Is env(1) common to enough platforms, for
> instance, or maybe we could add something to configure?

I'd agree that this is something which would be nice to clean up. I'd
have thought that it would be fine to use env for these. I've not
really seen a system on which it won't work and they are mostly
examples or functions so people can always fix the line. I would
suggest though putting a #! on the second line, possibly with a comment
so it is easier for anyone to work out how to fix it if the env trick
fails. For the example #!, I'd use /usr/local/bin as it is the default
prefix when compiling zsh and fairly common for perl too. I'm not
fussed though - having consistency is worth more.

The only one which slightly concerns me is Test/ztst.zsh but I don't
know much about the workings of the test system. As long as make check
will always work.

Setting the #! lines would be quite simple from configure but I'm not
sure it is worth it for the extra complexity and potential for things
to break.

Oliver

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

Re: /usr/local/bin/perl

[Adam Spiers]

Dragging up an old topic ...

Oliver Kiddle (okiddle@yahoo.co.uk) wrote:
> --- Adam Spiers <adam@spiers.net> wrote:
> > The following scripts hardcode binary locations (excluding /bin/sh
> 
> > Can we avoid this?  Is env(1) common to enough platforms, for
> > instance, or maybe we could add something to configure?
> 
> I'd agree that this is something which would be nice to clean up. I'd
> have thought that it would be fine to use env for these.

I'm not so sure env is any use now, as it appears to break if you
specify any switch, e.g.

  #!/usr/bin/env perl -w

breaks with

  env: perl -w: No such file or directory

Pretty remarkably braindead IMHO, but there we go.

> Setting the #! lines would be quite simple from configure but I'm not
> sure it is worth it for the extra complexity and potential for things
> to break.

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> The only reason that I've added #! lines anywhere is so that emacs will
> start up in shell script mode and select the correct syntax.
> 
> }    Util/helpfiles           :   #!/usr/bin/perl -- -*-perl-*-
> 
> The -*- perl -*- is extraneous there, at least in newer versions of emacs.
> It'll figure it out from the tail of the #! path.

Yep.

> }    Test/ztst.zsh            :   #!/usr/local/bin/zsh -f
> 
> That should be ".../zsh -f +Z".

Indeed, and I believe that I've had tests misleadingly fail through
running `make test' before `make install' as a result of that.  Shall
I change it then?

> If you put env in the #! line -- or put the #! line anywhere but as the
> first line in the script -- it foils emacs' algorithm for figuring out
> which mode to start in.  Same issue if you put some kind of @...@ thing
> for configure there.  Not that this should be the primary reason for any
> decision that we make, but at least consider it.

We can persuade emacs to use the right mode using the other method:

  # Local Variables:
  # mode:cperl
  # End:

should do it.

If we use configure, presumably that would mean having (say)
Utils/helpfiles auto-generated from Utils/helpfiles.in?  My vote is
for that option.

Re: /usr/local/bin/perl

[Bart Schaefer]

On Aug 15,  3:54pm, Adam Spiers wrote:
}
} > }    Test/ztst.zsh            :   #!/usr/local/bin/zsh -f
} > 
} > That should be ".../zsh -f +Z".
} 
} Indeed, and I believe that I've had tests misleadingly fail through
} running `make test' before `make install' as a result of that.

You shouldn't have.  `make test' explicitly calls zsh by full path and
passes it ztst.zsh by name.

You might have had failures trying to run tests by hand with
	./ztst.zsh B01cd.ztst
or some such, but the "right" way to do that is
	make test TESTNUM=B01

} Shall I change it then?

I'm not sure it'll help, as many OSs won't accept more than one argument
after the command path when interpreting a #! line.  (That's likely why
you are having trouble with `env perl -w'.)

} > If you put env in the #! line -- or put the #! line anywhere but as the
} > first line in the script -- it foils emacs' algorithm for figuring out
} > which mode to start in.  Same issue if you put some kind of @...@ thing
} > for configure there.  Not that this should be the primary reason for any
} > decision that we make, but at least consider it.
} 
} We can persuade emacs to use the right mode using the other method:
} 
}   # Local Variables:
}   # mode:cperl
}   # End:
} 
} should do it.

Please don't.  I find it aesthetically displeasing to have that cruft
at the end of every file, and I hate having emacs stop during file load
to ask whether it should pay attention to it, and it's not secure to
simply always accept it.  I'd rather just type M-x cperl-mode if emacs
has got it wrong.

} If we use configure, presumably that would mean having (say)
} Utils/helpfiles auto-generated from Utils/helpfiles.in?  My vote is
} for that option.

Yes, that would be it, but my vote is still to avoid mucking with this
in configure.  Maybe something like the following, run through the
just-compiled zsh?

--- 8< --- snip --- 8< ---
# Src/zsh -f path_to_this_file path_to_file_to_fix ${bindir}
setopt nobanghist
command=( $(sed -n -e '1s/^#!//p' $1) )
if [[ -n "$command" ]]; then
    if [[ ${command[1]:t} == zsh ]]; then
	command[1]=$2/zsh
    else
	command[1]=$(whence -p ${command[1]:t})
    fi
    if [[ -n "$command[1]" ]]; then
	echo "#!$command" > $1.fix &&
	sed -e 1d $1 >> $1.fix &&
	mv $1 $1.orig &&
	mv $1.fix $1
    fi
fi
--- 8< --- snip --- 8< ---

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: /usr/local/bin/perl

[Adam Spiers]

Bart Schaefer (schaefer@brasslantern.com) wrote:
> On Aug 15,  3:54pm, Adam Spiers wrote:
> }
> } > }    Test/ztst.zsh            :   #!/usr/local/bin/zsh -f
> } > 
> } > That should be ".../zsh -f +Z".
> } 
> } Indeed, and I believe that I've had tests misleadingly fail through
> } running `make test' before `make install' as a result of that.
> 
> You shouldn't have.  `make test' explicitly calls zsh by full path and
> passes it ztst.zsh by name.

Ahah.  Ignore that then; the failures have been fixed now anyway.

> } Shall I change it then?
> 
> I'm not sure it'll help,

Agreed, now that I know how make test works.

> as many OSs won't accept more than one argument after the command
> path when interpreting a #! line. (That's likely why you are having
> trouble with `env perl -w'.)

Gosh, looks like that applies even to a standard Linux box.  How
extraordinary.  What's the reasoning behind that, I wonder?

> } We can persuade emacs to use the right mode using the other method:
> } 
> }   # Local Variables:
> }   # mode:cperl
> }   # End:
> } 
> } should do it.
> 
> Please don't.  I find it aesthetically displeasing to have that cruft
> at the end of every file, and I hate having emacs stop during file load
> to ask whether it should pay attention to it, and it's not secure to
> simply always accept it.  I'd rather just type M-x cperl-mode if emacs
> has got it wrong.

Agreed, it is pretty nasty.  There are other elisp hacks you can solve
the problem with anyway.

> } If we use configure, presumably that would mean having (say)
> } Utils/helpfiles auto-generated from Utils/helpfiles.in?  My vote is
> } for that option.
> 
> Yes, that would be it, but my vote is still to avoid mucking with this
> in configure.  Maybe something like the following, run through the
> just-compiled zsh?

I suppose that's fine, as long as it wouldn't mess things up if you
ran it twice.  I still slightly prefer going via configure, as that
way you're not altering CVS files.  You probably have a more
convincing argument the other way though :-)

Re: /usr/local/bin/perl

[Bart Schaefer]

On Aug 16,  3:12pm, Adam Spiers wrote:
} Subject: Re: /usr/local/bin/perl
}
} > } If we use configure, presumably that would mean having (say)
} > } Utils/helpfiles auto-generated from Utils/helpfiles.in?  My vote is
} > } for that option.
} > 
} > Yes, that would be it, but my vote is still to avoid mucking with this
} > in configure.  Maybe something like the following, run through the
} > just-compiled zsh?
} 
} I suppose that's fine, as long as it wouldn't mess things up if you
} ran it twice.  I still slightly prefer going via configure, as that
} way you're not altering CVS files.  You probably have a more
} convincing argument the other way though :-)

Strangely enough, I don't, or at least not directly.

I just think it's a waste of effort.  None of those files actually gets
installed anywhere (except the two in Functions/Misc, and they really
are meant to be shell functions and shouldn't have a #! line at all,
nor should "reporter" for that matter).  If they *were* installed, I'd
recommend fixing the #! as part of the installation process; but they
aren't, so there's no reason to have a separate (and nonfunctional)
"source" file as well as a "compiled" one.

So I'm willing to bend a little and provide a way for you to fix them
up if you want to install them yourself, but I don't want more clutter
in the source tree and the configure script if we aren't going to make
installing them a part of the regular build process.

Even if there were separate source and compiled files, I still wouldn't
want to do it with configure.  A "make"-time transformation with a little
script like the one I supplied would be sufficient.

(Looking back at your original message, I'm curious how Util/helpfiles
manages to appear twice with two different #! lines.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: /usr/local/bin/perl

[Bart Schaefer]

On Mar 27,  2:28pm, Adam Spiers wrote:
} Subject: /usr/local/bin/perl
}
} This must have come up before, but I can't see it in the archives.
} 
} The following scripts hardcode binary locations (excluding /bin/sh
} since if a system can't cope with that ...) :

The only reason that I've added #! lines anywhere is so that emacs will
start up in shell script mode and select the correct syntax.

}    Util/helpfiles           :   #!/usr/bin/perl -- -*-perl-*-

The -*- perl -*- is extraneous there, at least in newer versions of emacs.
It'll figure it out from the tail of the #! path.

}    Test/ztst.zsh            :   #!/usr/local/bin/zsh -f

That should be ".../zsh -f +Z".

} Can we avoid this?  Is env(1) common to enough platforms, for
} instance, or maybe we could add something to configure?

If you put env in the #! line -- or put the #! line anywhere but as the
first line in the script -- it foils emacs' algorithm for figuring out
which mode to start in.  Same issue if you put some kind of @...@ thing
for configure there.  Not that this should be the primary reason for any
decision that we make, but at least consider it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net