[fpc-devel] bugreport: FPC 1.9.8 installer, i386-FreeBSD

[Marco van de Voort]

> 
> > bash is a superset of a sh shell, the .sh extension for bash scripts is
> > common, and has nothing to do with GNU. It was already that way on 4.4BSD.
> 
> 4.4BSD had bash???

No. Even FreeBSD still has bash as port. However it was commonly installed.

> And why do you say, it has nothing to do with GNU? 

I meant GNU orientation of OS/distro's in general.

> Okay, bash is very common nowadays. But for example zsh is also a 
> superset of sh, but if you use it's extentions without mentioning it, 
> you also might get very irritated reactions. ;-)

zsh is much less common than bash. E.g. FreeBSD comes without it, but
if you install a handful of ports, you already have it.
 
> > > Or better rewrite it to be usable with a standard-shell.
> > 
> > I prefer not, it is not worth the effort.
> 
> I'm going have a look at it this week. 
> Shall I send it to the list, or to whom?

Look first what needs to be done. The result must be maintainable. (keep in
mind that most other devels must be able to maintain and test it)
 
> > Define _properly_? The IDE is not configured by the installer. Does it
> > start?
> 
> Okay I could install it by hand...
> But nevertheless it's a bug in the installer-script.
> 
> I had a deeper look at it.
> The script says:
> | rm -f $EXECDIR/fp
> | ln -sf $LIBDIR/fp $EXECDIR/fp
> but the package has the binary in bin/, not in lib/...
> So the binary is deleted and the symlink points to nowhere.

Ok. Will try to see if we can do something about that for the next release.
 
> > Pascal is said to be a B&D language by people that don't grasp certain
> > concepts, usually newbies using Basic, or even plain C because it is l33t.
> 
> Even ESR says so.

ESR is also commonly considered to be a gunwielding maniac :-)

More importantly though, ESR is a C centric, and thus he inherits the lingo. No
surprise that he doesn't see the merits of Pascal.

> Well, okay, I can live with it, I just was surprised, because I was used 
> to do so.

I think it is best to simply inventarise what the bash specific parts are.

If they are details, and relatively non-intrusive, we can adapt it, and add
it to the wiki for future package builders.

If it is problematic, then we simply keep it bash.