gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: <bug> shell scripts fail when /bin/sh <> /bin/bash


From: Gour
Subject: [Gnumed-devel] Re: <bug> shell scripts fail when /bin/sh <> /bin/bash
Date: Mon, 04 Aug 2008 08:18:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>>>>> "Karsten" == Karsten Hilbert <address@hidden> writes:

Karsten> Well, *that* isn't true and IMO would be a rather shameful
Karsten> requirement. 

Heh, what if user run e.g. fish shell which is not POSIX and to rung two
commands uses: command1; and command2 syntax, and moreover, user does
not have bash?


Karsten> Windows doesn't even *have* a POSIX compliant
Karsten> shell (not sure about cygwin). 

Right. Another reason to eliminate those shell scripts.


Karsten> It is only a few helper shell scripts which have bashisms in
Karsten> them which I would rather either fix or explicitely make them
Karsten> require bash (as they do now).

But some distros are replacing bash with dash and many run zsh. Why not
eliminate bash?

Karsten> Most of those shell scripts are platform specific anyways.
Karsten> That's why they are shell scripts in the first place - they
Karsten> automate steps one would do on the command line.

Right, but if we can make them into Python for which we know it's on
every platform where GNUmed is supposed to work, then we'd have one
headache less.

bash is one of the reasons why it's not possible to use autoconf
mechanism on Win...

Karsten> Sure, why not. Which one are you thinking about ? It'll make a
Karsten> lot more sense for some than for others.

I'm thinking about ALL :-)

Karsten> Some of the shell scripts we'll keep in any case, however, such
Karsten> as gm-from-cvs.sh or /usr/bin/gnumed, 

Hmm...first of all I believe GNUmed will move away from CVS.

Then, instead of maintaining two scripts (*.bat & *.cvs), why not having
only one in Python?

Moreover, the title Get and run GNUmed source code from CVS (Windows)
I'd replace by producing GNUmed releases more often (incremental
releases) and/or by producing regular 'semi-stable' snapshot.

Does any of GNUmed developers use Windows as developing platform?

I'd also expect that the application (/usr/bin/gnumed) is called as
native (Python) script and not as shell script and I believe that the
whole install procedure can be improved making GNUmed more
distro-friendly so it can be put (included) in more distros.

Then, by having GUI installer for Windows, it will be very easy to
install it everywhere.

Karsten> because they serve quite specific purposes for which the shell
Karsten> is the appropriate level of abstraction.

I agree that shell scripts have their (specific) purpose, but in this
case, imho, we are talking about multi-platform abstraction by using
Python for those tasks 'cause shell scripts cannot provide enough
abstraction - we need *.sh & *.bat for the same purpose, or there is
e.g. check-prerequisites in both *.py and *.sh version...


All in all, my idea is to make GNUmed ship with less deps and make it
easier to install multi-platform-wise which is not possible by using
(ba)sh scripts.


Sincerely,
Gour


-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------

Attachment: pgppvhfzjwrjS.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]