/bin/sh portability question

/bin/sh portability question

[Peter Eriksen]

Hello,

It seems things are progressing nicely with regard to
Solaris portability.  However, I still have a few problems:

1) Maybe I didn't notice some new configuration option,
   but strcasestr is still not found with a simple "gmake".

2) In many of the shell scripts there is the idiom:

      #!/bin/sh
      
      cmd=
      path=$(dirname $0)
      case "$#" in
      0)      ;;
      *)      cmd="$1"
              shift
 
   When run, this gives the error:

      ./git.sh: syntax error at line 4: `path=$' unexpected

   I think it's because (on my Solaris at least), sh is really 
   sh and is not symlinked to bash, and sh doesn't like that 
   syntax.  Are there any good solutions to this other than
   making the administrators actually change sh to a symlink,
   (which I tried)?

/Peter

Re: /bin/sh portability question

[Junio C Hamano]

"Peter Eriksen" <s022018@student.dtu.dk> writes:

> 1) Maybe I didn't notice some new configuration option,
>    but strcasestr is still not found with a simple "gmake".

Perhaps "gmake NO_STRCASESTR=YesPlease"?

Do people use glibc or other alternative C libraries on Solaris
these days?  If nobody does, and everybody on SunOS lack
strcasestr, we could make SunOS imply NO_STRCASESTR in the
Makefile.

> 2) In many of the shell scripts there is the idiom:

>    I think it's because (on my Solaris at least), sh is really 
>    sh and is not symlinked to bash, and sh doesn't like that 
>    syntax.

Writing $(command) instead of `command` is not a bashism; Korn
supports it and even ash seems to.  But saying that would not
reduce the pain from non-sysadmins.

In many places we could just rewrite them to old-timer back-tick
form, unless we nest, in which case you would end up doing
something like this for readability:

	foo=$(command $(command to compute arg to it))

	arg=`command to compute arg to it`
        foo=`command "$arg"`

I haven't assessed the extent of damage if we tried to use ``
for portability lately (I did once, and it did not look too bad
back then).  If somebody comes up with a readable patch, I might
be persuaded to take it [*1*].

Another thing that will bite you is the use of shell arrays -- I
was trying to stay away from it but at least git-grep uses it
now (and hopefully nobody else).  It may not be a bad idea to
rewrite that one script in Perl or Python.


[Footnotes]

*1* Personally I feel that the only bug in Bourne was that it
did not spell command substitution as $().

Re: /bin/sh portability question

[Sean]

On Fri, September 23, 2005 4:24 am, Junio C Hamano said:

> I haven't assessed the extent of damage if we tried to use ``
> for portability lately (I did once, and it did not look too bad
> back then).  If somebody comes up with a readable patch, I might
> be persuaded to take it [*1*].

Junio,

It sounds like changing the sha-bang line to "#!/bin/bash" would fix the
problem on Solaris.  As an aside, it would improve vi syntax highlighting
as well.  Does any target system lack bash?

If not, would you accept a patch that first converted the shell scripts to
#!/bin/bash and then added a "make install" option that allowed them to be
replaced?   Something like "make install S=/bin/ash" for instance?

Sean

Re: /bin/sh portability question

[Sean]

On Fri, September 23, 2005 4:24 am, Junio C Hamano said:

> I haven't assessed the extent of damage if we tried to use ``
> for portability lately (I did once, and it did not look too bad
> back then).  If somebody comes up with a readable patch, I might
> be persuaded to take it [*1*].

Junio,

It sounds like changing the sha-bang line to "#!/bin/bash" would fix the
problem on Solaris.  As an aside, it would improve vi syntax highlighting
as well.  Does any target system lack bash?

If not, would you accept a patch that first converted the shell scripts to
#!/bin/bash and then added a "make install" option that allowed them to be
replaced?   Something like "make install S=/bin/ash" for instance?

Sean

Re: /bin/sh portability question

[Junio C Hamano]

"Sean" <seanlkml@sympatico.ca> writes:

> If not, would you accept a patch that first converted the shell scripts to
> #!/bin/bash and then added a "make install" option that allowed them to be
> replaced?   Something like "make install S=/bin/ash" for instance?

    $ make SHELL_PATH=/bin/bash

Perhaps?

Re: /bin/sh portability question

[Sean]

On Fri, September 23, 2005 5:19 am, Junio C Hamano said:
> "Sean" <seanlkml@sympatico.ca> writes:
>
>> If not, would you accept a patch that first converted the shell scripts
>> to
>> #!/bin/bash and then added a "make install" option that allowed them to
>> be
>> replaced?   Something like "make install S=/bin/ash" for instance?
>
>     $ make SHELL_PATH=/bin/bash
>
> Perhaps?
>

Heh.. so you've already got that working :o)   So on Solaris one fix would
be to just use the SHELL_PATH setting when installing to point to
/bin/bash.   What do you think about making /bin/bash the default?

Sean

Re: /bin/sh portability question

[Sean]

On Fri, September 23, 2005 5:19 am, Junio C Hamano said:
> "Sean" <seanlkml@sympatico.ca> writes:
>
>> If not, would you accept a patch that first converted the shell scripts
>> to
>> #!/bin/bash and then added a "make install" option that allowed them to
>> be
>> replaced?   Something like "make install S=/bin/ash" for instance?
>
>     $ make SHELL_PATH=/bin/bash
>
> Perhaps?
>

Heh.. so you've already got that working :o)   So on Solaris one fix would
be to just use the SHELL_PATH setting when installing to point to
/bin/bash.   What do you think about making /bin/bash the default?

Sean

Re: /bin/sh portability question

[Nico -telmich- Schottelius]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

Sean [Fri, Sep 23, 2005 at 06:34:45AM -0400]:
> On Fri, September 23, 2005 5:19 am, Junio C Hamano said:
> > "Sean" <seanlkml@sympatico.ca> writes:
> >
> >> If not, would you accept a patch that first converted the shell scripts
> >> to
> >> #!/bin/bash and then added a "make install" option that allowed them to
> >> be
> >> replaced?   Something like "make install S=/bin/ash" for instance?
> >
> >     $ make SHELL_PATH=/bin/bash
> >
> > Perhaps?
> >
> 
> Heh.. so you've already got that working :o)   So on Solaris one fix would
> be to just use the SHELL_PATH setting when installing to point to
> /bin/bash.   What do you think about making /bin/bash the default?

I think it's a bad idea, because some systems do not have and want bash,
because it's unneeded. On all systems here we've ash as /bin/sh and
/bin/zsh as primary user shell. Thus, /bin/bash does not exist, because
it's not as comfortable as zsh and not as small as ash.

Nico,
   who really likes man bash (very well documentated), but not the shell itself

-- 
Latest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)
Open Source nutures open minds and free, creative developers.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: /bin/sh portability question

[Sean]

On Sun, September 25, 2005 3:26 pm, Nico -telmich- Schottelius said:

> I think it's a bad idea, because some systems do not have and want bash,
> because it's unneeded. On all systems here we've ash as /bin/sh and
> /bin/zsh as primary user shell. Thus, /bin/bash does not exist, because
> it's not as comfortable as zsh and not as small as ash.

Hi Nico,

My guess is that your system configuration is in the minority and that
most target systems have bash installed today.  But all you'd have to do
is make a link from /bin/zsh to /bin/bash, or use the SHELL_PATH variable
to change all the scripts to /bin/zsh at install time.

Sean

Re: /bin/sh portability question

[Sean]

On Sun, September 25, 2005 3:26 pm, Nico -telmich- Schottelius said:

> I think it's a bad idea, because some systems do not have and want bash,
> because it's unneeded. On all systems here we've ash as /bin/sh and
> /bin/zsh as primary user shell. Thus, /bin/bash does not exist, because
> it's not as comfortable as zsh and not as small as ash.

Hi Nico,

My guess is that your system configuration is in the minority and that
most target systems have bash installed today.  But all you'd have to do
is make a link from /bin/zsh to /bin/bash, or use the SHELL_PATH variable
to change all the scripts to /bin/zsh at install time.

Sean

Re: /bin/sh portability question

[Junio C Hamano]

"Peter Eriksen" <s022018@student.dtu.dk> writes:

> It seems things are progressing nicely with regard to
> Solaris portability.

Good to have a Solaris user.  I have one patch that I've been
keeping in the proposed updates branch, waiting for a
comfirmation or 'not-good-enough-for-me' answer from people that
have cURL installed in nonstandard places.

------------
Subject: [PATCH] CURLDIR in Makefile
From: Patrick Mauritz <oxygene@studentenbude.ath.cx>
Date: 1127139079 +0200

Support systems that do not install curl headers and libraries
in /usr/{include,lib}.

Signed-off-by: Patrick Mauritz <oxygene@studentenbude.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 Makefile |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

a5ebfc164f8380eb4c1c2ff92082687c3cb0b39d
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -9,6 +9,9 @@
 # Define NO_CURL if you do not have curl installed.  git-http-pull is not
 # built, and you cannot use http:// and https:// transports.
 #
+# Define CURLDIR=/foo/bar if your curl header and library files are in
+# /foo/bar/include and /foo/bar/lib directories.
+#
 # Define NO_STRCASESTR if you don't have strcasestr.
 #
 # Define PPC_SHA1 environment variable when running make to make use of
@@ -131,6 +134,13 @@ ifdef WITH_SEND_EMAIL
 endif
 
 ifndef NO_CURL
+	ifdef CURLDIR
+		# This is still problematic -- gcc does not want -R.
+		CFLAGS += -I$(CURLDIR)/include
+		CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
+	else
+		CURL_LIBCURL = -lcurl
+	endif
 	PROGRAMS += git-http-fetch
 endif
 
@@ -285,7 +295,7 @@ git-ssh-upload: rsh.o
 git-ssh-pull: rsh.o fetch.o
 git-ssh-push: rsh.o
 
-git-http-fetch: LIBS += -lcurl
+git-http-fetch: LIBS += $(CURL_LIBCURL)
 git-rev-list: LIBS += $(OPENSSL_LIBSSL)
 
 init-db.o: init-db.c

Re: /bin/sh portability question

[Peter Eriksen]

On Fri, Sep 23, 2005 at 02:07:07AM -0700, Junio C Hamano wrote:
> "Peter Eriksen" <s022018@student.dtu.dk> writes:
> 
> > It seems things are progressing nicely with regard to
> > Solaris portability.
> 
> Good to have a Solaris user.  I have one patch that I've been
> keeping in the proposed updates branch, waiting for a
> comfirmation or 'not-good-enough-for-me' answer from people that
> have cURL installed in nonstandard places.

GCC is not complaining.  :-)

My current make command is like this:

gmake NO_STRCASESTR=YesPlease CURLDIR=/opt/sfw/  \
      SHELL_PATH=/bin/bash INSTALL=ginstall install

There are two problems:

* First of all there really needs to be a TAR variable, 
  since Solaris tar doesn't like the C option. 

* Secondly I've noticed that git.sh and gitk don't get 
  their /bin/sh line changed during install.

/Peter

Re: /bin/sh portability question

[Junio C Hamano]

"Peter Eriksen" <s022018@student.dtu.dk> writes:

> GCC is not complaining.  :-)
>
> My current make command is like this:
>
> gmake NO_STRCASESTR=YesPlease CURLDIR=/opt/sfw/  \
>       SHELL_PATH=/bin/bash INSTALL=ginstall install
>
> There are two problems:
>
> * First of all there really needs to be a TAR variable, 
>   since Solaris tar doesn't like the C option. 
>
> * Secondly I've noticed that git.sh and gitk don't get 
>   their /bin/sh line changed during install.

Thanks.

Would something like the attached patch, on top of what I sent
out, look good?  I do not think bash vs ksh vs bourne makes a
difference in the case of gitk.

------------
[PATCH] Solaris: give a bit more built-in defaults.

Taking the make command line Peter Eriksen uses, give defaults
to SHELL_PATH, TAR, CURLDIR, NO_STRCASESTR, and INSTALL.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 Makefile           |   43 ++++++++++++++++++++++++++-----------------
 git-clone.sh       |    3 ++-
 templates/Makefile |   10 ++++++----
 3 files changed, 34 insertions(+), 22 deletions(-)

49cbdf77449687da471ee9289796f7c480e7bd73
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -27,8 +27,6 @@
 # Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
 # Patrick Mauritz).
 #
-# Define NO_GETDOMAINNAME if your library lack it (SunOS, Patrick Mauritz).
-#
 # Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
 #
 # Define COLLISION_CHECK below if you believe that SHA1's
@@ -63,6 +61,7 @@ GIT_PYTHON_DIR = $(prefix)/share/git-cor
 
 CC = gcc
 AR = ar
+TAR = tar
 INSTALL = install
 RPMBUILD = rpmbuild
 
@@ -133,17 +132,6 @@ ifdef WITH_SEND_EMAIL
 	SCRIPT_PERL += git-send-email.perl
 endif
 
-ifndef NO_CURL
-	ifdef CURLDIR
-		# This is still problematic -- gcc does not want -R.
-		CFLAGS += -I$(CURLDIR)/include
-		CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
-	else
-		CURL_LIBCURL = -lcurl
-	endif
-	PROGRAMS += git-http-fetch
-endif
-
 LIB_FILE=libgit.a
 
 LIB_H = \
@@ -166,6 +154,9 @@ LIB_OBJS = \
 LIBS = $(LIB_FILE)
 LIBS += -lz
 
+#
+# Platform specific tweaks
+#
 ifeq ($(shell uname -s),Darwin)
 	NEEDS_SSL_WITH_CRYPTO = YesPlease
 	NEEDS_LIBICONV = YesPlease
@@ -173,12 +164,28 @@ endif
 ifeq ($(shell uname -s),SunOS)
 	NEEDS_SOCKET = YesPlease
 	NEEDS_NSL = YesPlease
+	SHELL_PATH = /bin/bash
+	NO_STRCASESTR = YesPlease
+	CURLDIR = /opt/sfw
+	INSTALL = ginstall
+	TAR = gtar
 	PLATFORM_DEFINES += -D__EXTENSIONS__
 endif
 ifneq (,$(findstring arm,$(shell uname -m)))
 	ARM_SHA1 = YesPlease
 endif
 
+ifndef NO_CURL
+	ifdef CURLDIR
+		# This is still problematic -- gcc does not want -R.
+		CFLAGS += -I$(CURLDIR)/include
+		CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
+	else
+		CURL_LIBCURL = -lcurl
+	endif
+	PROGRAMS += git-http-fetch
+endif
+
 ifndef SHELL_PATH
 	SHELL_PATH = /bin/sh
 endif
@@ -245,6 +252,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
 	  $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
 	  gitk
 
+export TAR INSTALL DESTDIR
 ### Build rules
 
 all: $(PROGRAMS) $(SCRIPTS)
@@ -254,7 +262,8 @@ all:
 
 git: git.sh Makefile
 	rm -f $@+ $@
-	sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' <$@.sh >$@+
+	sed -e '1s|#!.*/sh|#!$(SHELL_PATH)|' \
+	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' <$@.sh >$@+
 	chmod +x $@+
 	mv $@+ $@
 
@@ -356,7 +365,7 @@ dist: git-core.spec git-tar-tree
 	./git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar
 	@mkdir -p $(GIT_TARNAME)
 	@cp git-core.spec $(GIT_TARNAME)
-	tar rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git-core.spec
+	$(TAR) rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git-core.spec
 	@rm -rf $(GIT_TARNAME)
 	gzip -f -9 $(GIT_TARNAME).tar
 
@@ -365,7 +374,7 @@ rpm: dist
 
 deb: dist
 	rm -rf $(GIT_TARNAME)
-	tar zxf $(GIT_TARNAME).tar.gz
+	$(TAR) zxf $(GIT_TARNAME).tar.gz
 	dpkg-source -b $(GIT_TARNAME)
 	cd $(GIT_TARNAME) && fakeroot debian/rules binary
 
@@ -380,5 +389,5 @@ clean:
 	rm -f git-core_$(GIT_VERSION)-*.deb git-core_$(GIT_VERSION)-*.dsc
 	rm -f git-tk_$(GIT_VERSION)-*.deb
 	$(MAKE) -C Documentation/ clean
-	$(MAKE) -C templates/ clean
+	$(MAKE) -C templates clean
 	$(MAKE) -C t/ clean
diff --git a/git-clone.sh b/git-clone.sh
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -139,7 +139,8 @@ yes,yes)
 	then
 		HEAD=HEAD
 	fi
-	tar Ccf "$repo" - refs $HEAD | tar Cxf "$D/.git" - || exit 1
+	(cd "$repo" && tar cf - refs $HEAD) |
+	(cd "$D/.git" && tar xf -) || exit 1
 	;;
 *)
 	case "$repo" in
diff --git a/templates/Makefile b/templates/Makefile
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -1,8 +1,9 @@
 # make and install sample templates
 
-INSTALL=install
-prefix=$(HOME)
-template_dir=$(prefix)/share/git-core/templates/
+INSTALL ?= install
+TAR ?= tar
+prefix ?= $(HOME)
+template_dir ?= $(prefix)/share/git-core/templates/
 # DESTDIR=
 
 all: boilerplates custom
@@ -35,4 +36,5 @@ clean:
 
 install: all
 	$(INSTALL) -d -m755 $(DESTDIR)$(template_dir)
-	tar Ccf blt - . | tar Cxf $(DESTDIR)$(template_dir) -
+	(cd blt && $(TAR) cf - .) | \
+	(cd $(DESTDIR)$(template_dir) && $(TAR) xf -)

Re: /bin/sh portability question

[Junio C Hamano]

"Peter Eriksen" <s022018@student.dtu.dk> writes:

> Here are some small problems to begin with.

Thanks.  Next time, please format your patch according to
Documentation/SubmittingPatches.  Your MUA ate tabs and leading
whitespaces from the diff, and you lack Signed-off-by line.

I think you need to pass down SHELL_PATH, and prepare for people
running 'make' by hand in t/ directory.

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -252,7 +252,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
 	  $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
 	  gitk
 
-export TAR INSTALL DESTDIR
+export TAR INSTALL DESTDIR SHELL_PATH
 ### Build rules
 
 all: $(PROGRAMS) $(SCRIPTS)
diff --git a/t/Makefile b/t/Makefile
--- a/t/Makefile
+++ b/t/Makefile
@@ -4,8 +4,9 @@
 #
 
 #GIT_TEST_OPTS=--verbose --debug
+SHELL_PATH ?= $(SHELL)
 

BTW, do you have access to a Linux machine to play with?  It
would have caught this fairly easily.

Test of 'tar' timestamp would also fail if you do not use
'gtar', but as far as I know that test is the only place we
really rely on 'tar', so it may not be worth fixing.

'xargs -0' and 'find -print0' is really essential in some of the
git barebone scripts.  I think the one in git-reset can go, by 
unlinking in the Perl script instead of printing the name and
running "xargs -0 rm -f --" on it.

The one in git-commit I am not sure about.  We do want to make
it really generic and keep allowing LF in paths.  Maybe we would
want 'git-update-index --stdin [-z]' to read list of paths from
the standard input.

The one in git-grep I would not worry too much about; we should
rewrite the whole thing in Perl and the problem will disappear.

Re: /bin/sh portability question

[Patrick Mauritz]

On Fri, 2005-09-23 at 11:07, Junio C Hamano wrote:
> Good to have a Solaris user.  I have one patch that I've been
> keeping in the proposed updates branch, waiting for a
> comfirmation or 'not-good-enough-for-me' answer from people that
> have cURL installed in nonstandard places.
sorry for the lack of reponse.. apart from fixing up context (to match
0.99.7), this patch works here.


thanks,
patrick mauritz

Re: /bin/sh portability question

[H. Peter Anvin]

Peter Eriksen wrote:
> 
> 2) In many of the shell scripts there is the idiom:
> 
>       #!/bin/sh
>       
>       cmd=
>       path=$(dirname $0)
>       case "$#" in
>       0)      ;;
>       *)      cmd="$1"
>               shift
>  
>    When run, this gives the error:
> 
>       ./git.sh: syntax error at line 4: `path=$' unexpected
> 
>    I think it's because (on my Solaris at least), sh is really 
>    sh and is not symlinked to bash, and sh doesn't like that 
>    syntax.  Are there any good solutions to this other than
>    making the administrators actually change sh to a symlink,
>    (which I tried)?
> 

I think $(foo) is required by POSIX.

	-hpa

Re: /bin/sh portability question

[Morten Welinder]

> I think $(foo) is required by POSIX.

Indeed, but Solaris really does not have it.

Morten

Re: /bin/sh portability question

[Joel Becker]

On Fri, Sep 23, 2005 at 12:48:39PM -0700, H. Peter Anvin wrote:
> Peter Eriksen wrote:
> >      path=$(dirname $0)
> > ...
> >      ./git.sh: syntax error at line 4: `path=$' unexpected
> 
> I think $(foo) is required by POSIX.

	I believe that Solaris and others (AIX IIRC) have /bin/sh linked
to /bin/ksh, and it behaves as the POSIX shell when run as /bin/ksh, but
behaves as a much more true-to-bourne shell when run as /bin/sh.

Joel

-- 

"Nearly all men can stand adversity, but if you really want to
 test a man's character, give him power."
	- Abraham Lincoln

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: /bin/sh portability question

[H. Peter Anvin]

Joel Becker wrote:
> On Fri, Sep 23, 2005 at 12:48:39PM -0700, H. Peter Anvin wrote:
> 
>>Peter Eriksen wrote:
>>
>>>     path=$(dirname $0)
>>>...
>>>     ./git.sh: syntax error at line 4: `path=$' unexpected
>>
>>I think $(foo) is required by POSIX.
> 
> 
> 	I believe that Solaris and others (AIX IIRC) have /bin/sh linked
> to /bin/ksh, and it behaves as the POSIX shell when run as /bin/ksh, but
> behaves as a much more true-to-bourne shell when run as /bin/sh.
> 

But "sh" is required to be the POSIX shell (XSH page 850.)

Thus, they might have some braindamage where /usr/bin/sh is the POSIX 
shell and /bin/sh is a braindead shell.  Sigh.

	-hpa