anyone else writing Linux (or cross-system) applications in PHP?

[crankypuss]

(Apologies for the cross-post.)

I don't like bash, haven't seen anything that crude since back in the
days when I was writing FORTRAN and BASIC, so I've been writing all of
my local applications in PHP.

The folks who frequent comp.lang.php seem to be pretty web-centric which
makes sense as far as that goes. The folks who frequent the various
Linux fora seem pretty bash-centric which also makes sense as far as
that goes.

As an aside, I've been using Linux for long enough now to realize how
shell-centric it is as an operating system; I'm somewhat blown away by
that but it too makes its own kind of sense.

Is there a forum where the other folks (presuming there are any) who
have been writing applications in PHP hang out? Don't say "yeah dummy,
go to comp.lang.python" please, my homor quotient is maxed out for
today. <g>

[DanS]

Are you talking desktop applications?

And what kind of applications?


http://stackoverflow.com/questions/40870/why-dont-people-use-php-for-
desktop-applications

http://www.wisecodes.com/2009/03/create-php-desktop-applications-
calculator/

http://www.developertutorials.com/tutorials/php/building-desktop-
applications-in-php-8-02-01-934/

See what people are contributing for PHP at PlanetSourceCode.com:

http://www.planetsourcecode.com/vb/default.asp?lngWId=8

[Jonathan N. Little]

crankypuss wrote:
> (Apologies for the cross-post.)
>
> I don't like bash, haven't seen anything that crude since back in the
> days when I was writing FORTRAN and BASIC, so I've been writing all of
> my local applications in PHP.
>
> The folks who frequent comp.lang.php seem to be pretty web-centric which
> makes sense as far as that goes. The folks who frequent the various
> Linux fora seem pretty bash-centric which also makes sense as far as
> that goes.

Because for the web is where PHP originated. Get data, do something,
done. Not really suited for event driven apps. Late comer to acquiring
programming features like OOP. But it is evolving and things may change.

>
> As an aside, I've been using Linux for long enough now to realize how
> shell-centric it is as an operating system; I'm somewhat blown away by
> that but it too makes its own kind of sense.

I found bash so useful and powerful and confusing a bit at times. Beats
the stuffing out of MS batch files and easier than powershell for me.

>
> Is there a forum where the other folks (presuming there are any) who
> have been writing applications in PHP hang out? Don't say "yeah dummy,
> go to comp.lang.python" please, my homor quotient is maxed out for
> today. <g>

Because the python, perl, bash, c, and c++ is what is generally used.


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[Robert Heller]

At Sat, 02 Feb 2013 13:27:45 -0700 crankypuss <noe...@noemail.invalid> wrote:

>
> (Apologies for the cross-post.)
>
> I don't like bash, haven't seen anything that crude since back in the
> days when I was writing FORTRAN and BASIC, so I've been writing all of
> my local applications in PHP.

Bash is 'Born Again Shell' and is just an extended flavor of the Bourne
Shell, which is truly very simple in many ways. I don't think anyone
really considers bash seriously as something to write actual full-blown
applications in -- it never was (and is not) considered an 'application
programming language'. It is more meant either for basic simple
scripts -- short hand for commonly / repeatedly used command sequences
or for writing wrappers around applications that need some special
environment (like mozilla firefox). Tradionally, UNIX people write
their applications in C. These days, C++ has replaced C for larger
applications in many ways. Otherwise people use other high-level
languages, mostly scripting ones: Perl, Python (yech), Tcl(/Tk), Java,
XUL/JavaScript, etc. (And yes, for major number crunching
applications, FORTRAN is used heavily as COBOL is used heavily in
business applications.)

>
> The folks who frequent comp.lang.php seem to be pretty web-centric which
> makes sense as far as that goes. The folks who frequent the various
> Linux fora seem pretty bash-centric which also makes sense as far as
> that goes.
>
> As an aside, I've been using Linux for long enough now to realize how
> shell-centric it is as an operating system; I'm somewhat blown away by
> that but it too makes its own kind of sense.

The shell is what makes the world go round... :-) The shell is like
connective tissue. Not terribly exicting or useful on its own, but
without it, everything would fall apart.

>
> Is there a forum where the other folks (presuming there are any) who
> have been writing applications in PHP hang out? Don't say "yeah dummy,
> go to comp.lang.python" please, my homor quotient is maxed out for
> today. <g>

Yeah, I don't like Python either. Many people use Perl, but I consider
Perl something of a write-only language (Perl is the new APL). *I* use
Tcl(/Tk) for desktop applications, both for non-GUI scripting and for
GUI applications (even rather major ones). PHP is not really intended
for standalone *desktop* applications. It was *specificly* designed
for Web Applications and has many *core* features specific for such
applications. I don't believe there are any GUI toolkits available for
php.

>

--
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

[Keith D. Lee]

All:
What about Perl?
--
Sincerely,
Keith D. Lee

[M. Strobel]

The way it is now is the result of usage patterns and hype.

Just from memory, and I'm talking about usage, not existence:

First was the original (Bourne) shell, then came the Korn shell with some
improvements you see now in the "Bourne again" shell. Then there was the perl hype.
Then there was a short hype about Tcl, when after installation you had to build your
kernel, and could do "make xconfig" (Tcl/Tk script). Only then came PHP as "private
home page generator" or so. No wonder PHP is not used much on the command line.
Python was last to come.

Yes I think PHP Cli has got all it takes for programming, even signal handling. But
in system administration the bash is the shell that starts Linux up. And for
applications don't forget C, C++, Java, Pascal, and many many many ...

/Str.

[crankypuss]

On 02/02/2013 01:57 PM, DanS wrote:
> On Sat, 02 Feb 2013 13:27:45 -0700, crankypuss wrote:
>
>> (Apologies for the cross-post.)
>>
>> I don't like bash, haven't seen anything that crude since back in the
>> days when I was writing FORTRAN and BASIC, so I've been writing all of
>> my local applications in PHP.
>>
>> The folks who frequent comp.lang.php seem to be pretty web-centric which
>> makes sense as far as that goes. The folks who frequent the various
>> Linux fora seem pretty bash-centric which also makes sense as far as
>> that goes.
>>
>> As an aside, I've been using Linux for long enough now to realize how
>> shell-centric it is as an operating system; I'm somewhat blown away by
>> that but it too makes its own kind of sense.
>>
>> Is there a forum where the other folks (presuming there are any) who
>> have been writing applications in PHP hang out? Don't say "yeah dummy,
>> go to comp.lang.python" please, my homor quotient is maxed out for
>> today. <g>
>
> Are you talking desktop applications?

Mostly.

> And what kind of applications?

Whatever.

>
> http://stackoverflow.com/questions/40870/why-dont-people-use-php-for-
> desktop-applications
>
> http://www.wisecodes.com/2009/03/create-php-desktop-applications-
> calculator/
>
> http://www.developertutorials.com/tutorials/php/building-desktop-
> applications-in-php-8-02-01-934/
>
> See what people are contributing for PHP at PlanetSourceCode.com:
>
> http://www.planetsourcecode.com/vb/default.asp?lngWId=8
>

The last thing I want is more shitsucking web forums, but thanks anyway.

Discussion does not happen in web forums, the clumsiness of the
mechanism prohibits it.

[crankypuss]

On 02/02/2013 02:27 PM, Jonathan N. Little wrote:
> crankypuss wrote:
>> (Apologies for the cross-post.)
>>
>> I don't like bash, haven't seen anything that crude since back in the
>> days when I was writing FORTRAN and BASIC, so I've been writing all of
>> my local applications in PHP.
>>
>> The folks who frequent comp.lang.php seem to be pretty web-centric which
>> makes sense as far as that goes. The folks who frequent the various
>> Linux fora seem pretty bash-centric which also makes sense as far as
>> that goes.
>
> Because for the web is where PHP originated. Get data, do something,
> done. Not really suited for event driven apps.

I have code that says you're mistaken.

> Late comer to acquiring
> programming features like OOP. But it is evolving and things may change.

OOP is the worst thing that happened to PHP since mySQL.

>>
>> As an aside, I've been using Linux for long enough now to realize how
>> shell-centric it is as an operating system; I'm somewhat blown away by
>> that but it too makes its own kind of sense.
>
> I found bash so useful and powerful and confusing a bit at times. Beats
> the stuffing out of MS batch files and easier than powershell for me.

MS batch files, lol. Not familiar with powershell.

>>
>> Is there a forum where the other folks (presuming there are any) who
>> have been writing applications in PHP hang out? Don't say "yeah dummy,
>> go to comp.lang.python" please, my homor quotient is maxed out for
>> today. <g>
>
> Because the python, perl, bash, c, and c++ is what is generally used.

So it goes, eh? Everybody does what everybody has always done.

Well thanks, JNL. 'Preciate your reply.

[crankypuss]

On 02/02/2013 02:43 PM, Robert Heller wrote:
> At Sat, 02 Feb 2013 13:27:45 -0700 crankypuss <noe...@noemail.invalid> wrote:
>
>>
>> (Apologies for the cross-post.)
>>
>> I don't like bash, haven't seen anything that crude since back in the
>> days when I was writing FORTRAN and BASIC, so I've been writing all of
>> my local applications in PHP.
>
> Bash is 'Born Again Shell' and is just an extended flavor of the Bourne
> Shell, which is truly very simple in many ways. I don't think anyone
> really considers bash seriously as something to write actual full-blown
> applications in -- it never was (and is not) considered an 'application
> programming language'. It is more meant either for basic simple
> scripts -- short hand for commonly / repeatedly used command sequences
> or for writing wrappers around applications that need some special
> environment (like mozilla firefox).

From what I've seen, bash is commonly used for "applications" and in
the process it's commonly pushed way beyond its limits by what appears
to be the standard practice of not checking for errors. Probably my
glasses have lint stuck to them or something. <g>

> Tradionally, UNIX people write
> their applications in C. These days, C++ has replaced C for larger
> applications in many ways. Otherwise people use other high-level
> languages, mostly scripting ones: Perl, Python (yech), Tcl(/Tk), Java,
> XUL/JavaScript, etc. (And yes, for major number crunching
> applications, FORTRAN is used heavily as COBOL is used heavily in
> business applications.)
>
>>
>> The folks who frequent comp.lang.php seem to be pretty web-centric which
>> makes sense as far as that goes. The folks who frequent the various
>> Linux fora seem pretty bash-centric which also makes sense as far as
>> that goes.
>>
>> As an aside, I've been using Linux for long enough now to realize how
>> shell-centric it is as an operating system; I'm somewhat blown away by
>> that but it too makes its own kind of sense.
>
> The shell is what makes the world go round... :-) The shell is like
> connective tissue. Not terribly exicting or useful on its own, but
> without it, everything would fall apart.

I doubt that "everything would fall apart" but it might get a bit wobbly
until someone came up with some actual reliable bits to replace it.

>>
>> Is there a forum where the other folks (presuming there are any) who
>> have been writing applications in PHP hang out? Don't say "yeah dummy,
>> go to comp.lang.python" please, my homor quotient is maxed out for
>> today. <g>
>
> Yeah, I don't like Python either. Many people use Perl, but I consider
> Perl something of a write-only language (Perl is the new APL). *I* use
> Tcl(/Tk) for desktop applications, both for non-GUI scripting and for
> GUI applications (even rather major ones). PHP is not really intended
> for standalone *desktop* applications. It was *specificly* designed
> for Web Applications and has many *core* features specific for such
> applications. I don't believe there are any GUI toolkits available for
> php.

Yeah, there is plenty (meaning, "nearly enough") available in the way of
builtin functions, but PHP is web-oriented at least insofar as "echo"
and headers go.

What I'm using for desktop applications is something I'm building that
is (at present, anyway) based on ncurses. Except for the bits that need
to work with existing code, bits like nautilus scripts, and for that
kind of thing I'm using zenity which rather sucks but it only needs to
do a few simple things.

[The Natural Philosopher]

On 03/02/13 10:49, crankypuss wrote:
>
>
> So it goes, eh? Everybody does what everybody has always done.
>

when there really is no better reason to select, that becomes dominant
as a choice influencing factor.

people are there who know the language, books, support tutorials,
compilers (where appropriate), libraries..

In the real world these are far more relevant than it it supports some
academically interesting construction or not.


--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

[crankypuss]

On 02/02/2013 03:20 PM, Keith D. Lee wrote:
> All:
> What about Perl?
>

Enjoy. No reason not to go back to the predecessor of PHP. That's
where PHP came from, y'know. Some fellow whose name I don't recall
built it to do the things Perl wasn't set up for. google "PHP history"
there's a bit in wikipedia about it.

[crankypuss]

The big question in my sick mind is whether to build a distro that uses
PHP as its primary scripting language or build a new language that's
what PHP could have been if it hadn't been mucked-about by all and
sundry who gave it functions like is_array() and isset() and when a
language doesn't even have consistent naming conventions well there ya
go. <g>

Then they stuck on some OOP functionality and OOP is what everybody
thinks is the hot item but it's clumsier than hell to have to pass
around a this-pointer and you can't slip another layer into an existing
class derivation without rewriting half the world.

Of course at the same time there's the struggle over screen i/o,
everybody and his brother wants GUI which is fine except that character
mode has its uses as well. The obvious compromise is an embedded app
that uses PHP to write pages to an internal browser rendering engine but
html has its limitations and damned if I'm wanting to get involved in
javascript.

Meanwhile back at the ranch I'm building applications based on a
character-mode abstraction that runs on top of ncurses and just
basically working my way out in both directions from there.

Everybody needs a hobby, right? <g>

[J.O. Aho]

On 03/02/13 12:20, crankypuss wrote:

> The big question in my sick mind is whether to build a distro that uses
> PHP as its primary scripting language or build a new language that's
> what PHP could have been if it hadn't been mucked-about by all and
> sundry who gave it functions like is_array() and isset() and when a
> language doesn't even have consistent naming conventions well there ya
> go. <g>

There are loads of scripting languages, but you will always know that a
Linux (including Unix too) will have a shell installed, which makes the
shell scripting a lot more popular for you don't have to install another
dependency to be able to run. If REXX been built in by default in the
Linux/Unix world, then it would have been as popular for scripting as
Arexx in the Amiga community and replacing shell scripting with
something else will be something just for your own distro.

One thing talking against PHP is the memory leaking that happens over
time, writing a daemon you will have it to eat up memory and need to be
restarted and it don't help to use unset() every time you are finished
with a variable.

> Then they stuck on some OOP functionality and OOP is what everybody
> thinks is the hot item but it's clumsier than hell to have to pass
> around a this-pointer and you can't slip another layer into an existing
> class derivation without rewriting half the world.

Nothing forces you to use OOP, OOP has it's beauties, but not always the
optimal way to write the code.

> Of course at the same time there's the struggle over screen i/o,
> everybody and his brother wants GUI which is fine except that character
> mode has its uses as well.

Sure you can write desktop applications in PHP, but not all OS:es has
gtk/qt/ncurses bindings and not all Linux distributions has those
available from the official repository, which makes PHP a poor option to
write desktop applications.

> The obvious compromise is an embedded app
> that uses PHP to write pages to an internal browser rendering engine but
> html has its limitations and damned if I'm wanting to get involved in
> javascript.

PHP was made for the web and it's where it has it's strengths and to
make things faster and smother javascript will be a part of your life.


If you want something cross-platform, then look at mono, sure it's
larger to install than PHP, but the benefit is that you can make
applications that will run on multiple platforms.

--

//Aho

[The Natural Philosopher]

java is probably the most popular cross platform interpreted language.

[DanS]

Well if you haven't found discussions of what you're looking for on
Usenet, what else is there?

(However, I do agree that web forums usually do suck. Mainly because
they usually show no hierarchy and all posts appear just one after
another.)

[J.O. Aho]

On 03/02/13 12:50, The Natural Philosopher wrote:

>> If you want something cross-platform, then look at mono, sure it's
>> larger to install than PHP, but the benefit is that you can make
>> applications that will run on multiple platforms.
>>
> java is probably the most popular cross platform interpreted language.
>
>

Sure it is, but also the one which has been struggling with security
issues and do not feel to be something to recommend nowadays, but lets
see if Oracle has the will to fix the issues.

I have to say I feel C# applications on Linux to be smother than Java,
but then I don't use much of either.

--

//Aho

[J G Miller]

On Sunday, February 3rd, 2013, at 10:58:04h +0100, M. Strobel wrote:

> But in system administration the bash is the shell that starts Linux up.

Most of the major distributions do not use bash as the startup shell,
but dash to provide a Bourne shell (not Bourne Again shell).

[The Natural Philosopher]

On 03/02/13 12:47, J.O. Aho wrote:
> On 03/02/13 12:50, The Natural Philosopher wrote:
>
>>> If you want something cross-platform, then look at mono, sure it's
>>> larger to install than PHP, but the benefit is that you can make
>>> applications that will run on multiple platforms.
>>>
>> java is probably the most popular cross platform interpreted language.
>>
>>
> Sure it is, but also the one which has been struggling with security
> issues and do not feel to be something to recommend nowadays, but lets
> see if Oracle has the will to fix the issues.
>

No argument with that: I merely said it was popular.

> I have to say I feel C# applications on Linux to be smother than Java,
> but then I don't use much of either.
>

frankly if I were coding anything for a Linux desktop I'd use C/C++.

Mostly because the support is guaranteed, the libraries will all be
there, and that's what most of the rest is written in.

[M. Strobel]

And in which distributions /bin/sh is not a link to /bin/bash?

/Str.

[John Hasler]

M. Strobel writes:
> And in which distributions /bin/sh is not a link to /bin/bash?

Debian and derivatives. Debian has used Dash for some years.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[Jonathan N. Little]

crankypuss wrote:
> On 02/02/2013 02:27 PM, Jonathan N. Little wrote:
>> crankypuss wrote:
>>> (Apologies for the cross-post.)
>>>
>>> I don't like bash, haven't seen anything that crude since back in the
>>> days when I was writing FORTRAN and BASIC, so I've been writing all of
>>> my local applications in PHP.
>>>
>>> The folks who frequent comp.lang.php seem to be pretty web-centric which
>>> makes sense as far as that goes. The folks who frequent the various
>>> Linux fora seem pretty bash-centric which also makes sense as far as
>>> that goes.
>>
>> Because for the web is where PHP originated. Get data, do something,
>> done. Not really suited for event driven apps.
>
> I have code that says you're mistaken.

I don't think so. Since its original name was "Personal Home Page Tools"
for scripts to facilitate created personal webpages on a server speaks
to its origins. How an application interacts in with the user from a
webserver is very different from that of a desktop application. That
said, PHP is one of the easiest languages to get started on. I use it a
lot but never liked it double-butt-load of core commands, I mean com'on
PHP gods have you not ever hear of a command parameter? How many in
PHP's gaggle of "sort" commands vs Perl one: sort?

>
>> Late comer to acquiring
>> programming features like OOP. But it is evolving and things may change.
>
> OOP is the worst thing that happened to PHP since mySQL.
>
>>>
>>> As an aside, I've been using Linux for long enough now to realize how
>>> shell-centric it is as an operating system; I'm somewhat blown away by
>>> that but it too makes its own kind of sense.
>>
>> I found bash so useful and powerful and confusing a bit at times. Beats
>> the stuffing out of MS batch files and easier than powershell for me.
>
> MS batch files, lol.

You can get some things done, but it takes a lot of kung-foo!

> Not familiar with powershell.

Single word, "ugh".

>
>>>
>>> Is there a forum where the other folks (presuming there are any) who
>>> have been writing applications in PHP hang out? Don't say "yeah dummy,
>>> go to comp.lang.python" please, my homor quotient is maxed out for
>>> today. <g>
>>
>> Because the python, perl, bash, c, and c++ is what is generally used.
>
> So it goes, eh? Everybody does what everybody has always done.

I have been looking at python since there seems to be so much
development in that direction, but <groan> another language to
learn...maybe not so bad since the syntax is so different, unlike the
problems I suffer when I switch back and forth between Perl and PHP.

[Richard Kettlewell]

John Hasler <jha...@newsguy.com> writes:
> M. Strobel writes:

>> And in which distributions /bin/sh is not a link to /bin/bash?
> Debian and derivatives. Debian has used Dash for some years.

“is not a link to bash” is a little strong - /bin/sh could easily be
either dash or bash on a Debian system. I have systems with both
configurations, for instance.

(And on any given system the operator may have done something else
again.)

--
http://www.greenend.org.uk/rjk/

[John Hasler]

I wrote:
> Debian and derivatives. Debian has used Dash for some years.

Richard Kettlewell writes:
> “is not a link to bash” is a little strong - /bin/sh could easily be
> either dash or bash on a Debian system. I have systems with both
> configurations, for instance.

You can change it to whatever you want, of course, but it has been Dash
by default for years.

[M. Strobel]

Am 03.02.2013 15:16, schrieb John Hasler:
> M. Strobel writes:
>> And in which distributions /bin/sh is not a link to /bin/bash?
>
> Debian and derivatives. Debian has used Dash for some years.
>

Oh, and I have an Ubuntu here and did not notice. Dash is presumably faster, but is
only sh compatible. And the change forced people to adhere to the lower sh standards.

I would have tried to optimize bash, but then the shell syntax is awkward anyway.
Better use a full scripting language.

Size comparison executable plus linked libraries in Ubuntu 12.04:
dash 2021K
bash 3016K
tclsh 4191K
perl 4637K
python 8349K
PHP 17167K

/Str.

[John Hasler]

M. Strobel writes:
> Oh, and I have an Ubuntu here and did not notice.

As I said: Debian derivatives.

> Dash is presumably faster, but is only sh compatible. And the change
> forced people to adhere to the lower sh standards.

Bash is still an essential package and so always present. Maintainers
are free to use it in scripts. They just have to call it explicitly.
Bash is also the default login shell.

[crankypuss]

On 02/03/2013 08:17 AM, Jonathan N. Little wrote:
> crankypuss wrote:
>> On 02/02/2013 02:27 PM, Jonathan N. Little wrote:
>>> crankypuss wrote:
>>>> (Apologies for the cross-post.)
>>>>
>>>> I don't like bash, haven't seen anything that crude since back in the
>>>> days when I was writing FORTRAN and BASIC, so I've been writing all of
>>>> my local applications in PHP.
>>>>
>>>> The folks who frequent comp.lang.php seem to be pretty web-centric
>>>> which
>>>> makes sense as far as that goes. The folks who frequent the various
>>>> Linux fora seem pretty bash-centric which also makes sense as far as
>>>> that goes.
>>>
>>> Because for the web is where PHP originated. Get data, do something,
>>> done. Not really suited for event driven apps.
>>
>> I have code that says you're mistaken.
>
>
> I don't think so. Since its original name was "Personal Home Page Tools"
> for scripts to facilitate created personal webpages on a server speaks
> to its origins. How an application interacts in with the user from a
> webserver is very different from that of a desktop application.

It's okay if we disagree on this, you're allowed to be incorrect. <G>

As for how users interact with applications, if you think it's different
on the web vs on the desktop, I would claim that you haven't finished
generalizing your view of it. In either case the application presents
something, the user responds, rinse-and-repeat. The main difference
between a web-app and a desktop-app is the level of precision provided
by the interface and the amount of latency. I've built web-apps that
run equally well on the desktop. If you aren't aware of it, there is
(or, was) a guy in the Windows world who sells a shareware product to
facilitate writing desktop applications in PHP.

I'm not sure but I think it used to be available here,
http://www.desktopsolutions.com/
but he/they seem not to offer the package anymore, preferring to make
money providing services. It's been years, and I don't recall for sure
where I got the thing. It could have been this but I think this is
something new:

http://www.nusphere.com/products/phpdock.htm

Oooh, lookit what I found while looking for that link!
http://code.google.com/p/phpdesktop/

> That
> said, PHP is one of the easiest languages to get started on. I use it a
> lot but never liked it double-butt-load of core commands, I mean com'on
> PHP gods have you not ever hear of a command parameter? How many in
> PHP's gaggle of "sort" commands vs Perl one: sort?

The language has been hacked almost to death, yeah.

OTOH, when I think about going back and re-learning C, which I never
*really* learned well since I skipped from Assembler to C++, and then
dropped C++ as a bag-o-crap... it's like considering the idea of
spending money to hook up with your ex-wife's mother or something
equally disgusting.

>>> Late comer to acquiring
>>> programming features like OOP. But it is evolving and things may change.
>>
>> OOP is the worst thing that happened to PHP since mySQL.
>>
>>>>
>>>> As an aside, I've been using Linux for long enough now to realize how
>>>> shell-centric it is as an operating system; I'm somewhat blown away by
>>>> that but it too makes its own kind of sense.
>>>
>>> I found bash so useful and powerful and confusing a bit at times. Beats
>>> the stuffing out of MS batch files and easier than powershell for me.
>>
>> MS batch files, lol.
>
> You can get some things done, but it takes a lot of kung-foo!
>
>> Not familiar with powershell.
>
> Single word, "ugh".
>
>>
>>>>
>>>> Is there a forum where the other folks (presuming there are any) who
>>>> have been writing applications in PHP hang out? Don't say "yeah dummy,
>>>> go to comp.lang.python" please, my homor quotient is maxed out for
>>>> today. <g>
>>>
>>> Because the python, perl, bash, c, and c++ is what is generally used.
>>
>> So it goes, eh? Everybody does what everybody has always done.
>
> I have been looking at python since there seems to be so much
> development in that direction, but <groan> another language to
> learn...maybe not so bad since the syntax is so different, unlike the
> problems I suffer when I switch back and forth between Perl and PHP.
>

PHP has a few advantages. Lots of people use it for web-apps so there
are more PHP programmers out there than programmers for a
new-as-yet-untested language. If you can make your way through all the
gross crap, you can find a pony underneath. And syntactically it isn't
that difficult to automatically transliterate to some
new-as-yet-untested language. The language itself has some decent
features, reminiscent of Rexx. It ain't great but it's sufficient, imo.

[crankypuss]

And McDonalds probably sells more bad hamburgers than anybody else.

[Jonathan N. Little]

crankypuss wrote:
> On 02/03/2013 08:17 AM, Jonathan N. Little wrote:

<snip>

>> I don't think so. Since its original name was "Personal Home Page Tools"
>> for scripts to facilitate created personal webpages on a server speaks
>> to its origins. How an application interacts in with the user from a
>> webserver is very different from that of a desktop application.
>
> It's okay if we disagree on this, you're allowed to be incorrect. <G>

Not sure even if a smile can change history though.

>
> As for how users interact with applications, if you think it's different
> on the web vs on the desktop, I would claim that you haven't finished
> generalizing your view of it. In either case the application presents
> something, the user responds, rinse-and-repeat. The main difference
> between a web-app and a desktop-app is the level of precision provided
> by the interface and the amount of latency. I've built web-apps that
> run equally well on the desktop. If you aren't aware of it, there is
> (or, was) a guy in the Windows world who sells a shareware product to
> facilitate writing desktop applications in PHP.

But how it "runs" is different. A desktop app starts and has a message
loop that checks for user interaction. Responds and continues until
either program, user, or system terminates the processes. With the web
the php script receives its input via the web server, script runs and
does its stuff, creates the web page and terminates.

[J G Miller]

On Sunday, February 3rd, 2013, at 11:24:04h -0600, John Hasler wrote:

> M. Strobel writes:
>> Oh, and I have an Ubuntu here and did not notice.
>
> As I said: Debian derivatives.
>
>> Dash is presumably faster, but is only sh compatible. And the change
>> forced people to adhere to the lower sh standards.
>
> Bash is still an essential package and so always present.

Indeed so and nobody is or should be arguing otherwise.

The point raised was solely with respect to

"bash is the shell that starts Linux up."

> Maintainers are free to use it in scripts.

Certainly not boot time scripts and it appears that it
is frowned upon for other scripts.

<http://lintian.debian.org/tags/possible-bashism-in-maintainer-script.html>

Ubuntu also adopted the policy of not using bashisms in startup scripts.

<https://wiki.ubuntu.COM/DashAsBinSh>

> Bash is also the default login shell.

But can easily be changed to tcsh for the users. ;)

[Richard Kettlewell]

J G Miller <mil...@yoyo.ORG> writes:

> John Hasler wrote:

>> Maintainers are free to use it in scripts.
>
> Certainly not boot time scripts and it appears that it
> is frowned upon for other scripts.
>
> <http://lintian.debian.org/tags/possible-bashism-in-maintainer-script.html>
>
> Ubuntu also adopted the policy of not using bashisms in startup scripts.
>
> <https://wiki.ubuntu.COM/DashAsBinSh>

Neither of those pages contain instructions to avoid Bash. They just
tell you not to use Bashisms in scripts starting “#!/bin/sh”.

Notice for instance that (at least in sid) dash.preinst is a #!/bin/bash
script, but dash doesn’t appear on the lintian page.

--
http://www.greenend.org.uk/rjk/

[John Hasler]

I wrote:
> [Debian] maintainers are free to use [Bash] in scripts.

J G Miller writes:
> Certainly not boot time scripts and it appears that it
> is frowned upon for other scripts.

From the Debian Policy Manual:

All command scripts, including the package maintainer scripts inside
the package and used by dpkg, should have a #! line naming the shell
to be used to interpret them. In the case of Perl scripts this
should be #!/usr/bin/perl.

....

Shell scripts (sh and bash) other than init.d scripts should almost
certainly start with set -e so that errors are detected. init.d
scripts are something of a special case, due to how frequently they
need to call commands that are allowed to fail, and it may instead be
easier to check the exit status of commands directly. See Writing the
scripts, Section 9.3.2 for more information about writing init.d
scripts.

...

If a shell script requires non-SUSv3 features from the shell
interpreter other than those listed above, the appropriate shell must
be specified in the first line of the script (e.g., #!/bin/bash) and
the package must depend on the package providing the shell (unless
the shell package is marked "Essential", as in the case of bash).

...

If in doubt whether a script complies with these requirements, use
/bin/bash.

...

csh and tcsh should be avoided as scripting languages.

[J G Miller]

On Sunday, February 3rd, 2013, at 20:25:39h +0000, Richard Kettlewell wrote:

> Neither of those pages contain instructions to avoid Bash.

But this tends to suggest that bash should be avoided if possible.

From <http://www.debian.org/doc/debian-policy/ch-files.html>

QUOTE

You may wish to restrict your script to SUSv3 features plus the above set when
possible so that it may use /bin/sh as its interpreter. Checking your script
with checkbashisms from the devscripts package or running your script with an
alternate shell such as posh may help uncover violations of the above requirements.

If in doubt whether a script complies with these requirements, use /bin/bash.

UNQUOTE

> Notice for instance that (at least in sid) dash.preinst is a #!/bin/bash
> script, but dash doesn’t appear on the lintian page.

Well Debianistas do not always follow their own recommendations,
do they? ;)

{init.d/}# ls -1 | wc -l
120

{init.d/}# grep bash *
acpi-support:#!/bin/bash
console-log:#! /bin/bash
nfs-kernel-server:#!/bin/bash

{init.d}# grep '#! */bin/sh' * | wc -l
120

[Richard Yates]

On Sun, 03 Feb 2013 14:00:55 -0500, "Jonathan N. Little"
<lws...@gmail.com> wrote:

>crankypuss wrote:
>> On 02/03/2013 08:17 AM, Jonathan N. Little wrote:
>
><snip>
>
>>> I don't think so. Since its original name was "Personal Home Page Tools"
>>> for scripts to facilitate created personal webpages on a server speaks
>>> to its origins. How an application interacts in with the user from a
>>> webserver is very different from that of a desktop application.
>>
>> It's okay if we disagree on this, you're allowed to be incorrect. <G>
>
>Not sure even if a smile can change history though.

Especially when the tag is never closed!

[John Hasler]

Debian Policy is a standard for Debian maintainers and follows the usual
conventions. "You may wish" is not a synonym for "shall" or even for
"should".

[The Natural Philosopher]

That's amazing! 120-3 = 120!

[Richard Kettlewell]

J G Miller <mil...@yoyo.ORG> writes:

> Richard Kettlewell wrote:

>> Neither of those pages contain instructions to avoid Bash.
>
> But this tends to suggest that bash should be avoided if possible.
>
> From <http://www.debian.org/doc/debian-policy/ch-files.html>
>
> QUOTE
>
> You may wish to restrict your script to SUSv3 features plus the above
> set when possible so that it may use /bin/sh as its
> interpreter. Checking your script with checkbashisms from the
> devscripts package or running your script with an alternate shell
> such as posh may help uncover violations of the above requirements.
> If in doubt whether a script complies with these requirements, use
> /bin/bash.
>
> UNQUOTE

You seem to be reading “you may wish to” as “you should”, and perhaps to
have had trouble reading the “if in doubt” part at all.

--
http://www.greenend.org.uk/rjk/

[J G Miller]

On Sunday, February 3rd, 2013, at 22:59:15h +0000,

The Natural Philosopher wrote:

> That's amazing! 120-3 = 120!

My cut 'n' paste went wrong.

ls -1 | wc -l
123

[Martin]

On 02/03/2013 08:00 PM, Jonathan N. Little wrote:

>>> I don't think so. Since its original name was "Personal Home Page Tools"
>>> for scripts to facilitate created personal webpages on a server speaks
>>> to its origins. How an application interacts in with the user from a
>>> webserver is very different from that of a desktop application.
>>
>> It's okay if we disagree on this, you're allowed to be incorrect. <G>
>
> Not sure even if a smile can change history though.

you're totally right, PHP started out as "Private Home Page" and was
designed as an inline script for HTML templates, just like all the other
"XYZ Server Pages" in the early days.

For those with a sense of humour there is this comparison between perl
and PHP:

http://tnx.nl/php.html

[The Natural Philosopher]

yerrs. its like comparing cat shit to dog crap. Really if its on your
shoe, who gives a damn?

[Arno Welzel]

crankypuss, 2013-02-02 21:27:

[...]

> Is there a forum where the other folks (presuming there are any) who
> have been writing applications in PHP hang out? Don't say "yeah dummy,
> go to comp.lang.python" please, my homor quotient is maxed out for
> today. <g>

Maybe <http://gtk.php.net/> is what you are looking for.

But this is still very limited - i recommend to learn C++ and how to use
Qt. See <http://qt-project.org/downloads>.

Qt also provides "Qt Creator" - a nice IDE including GUI designer,
debugger etc.. (see <http://qt-project.org/wiki/Category:Tools::QtCreator>).


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[Arno Welzel]

crankypuss, 2013-02-03 11:49:

> On 02/02/2013 02:27 PM, Jonathan N. Little wrote:
[...]

>> Because for the web is where PHP originated. Get data, do something,
>> done. Not really suited for event driven apps.
>
> I have code that says you're mistaken.

In which way? How does your PHP code handle events without polling in an
endless loop?

[Arno Welzel]

Am 04.02.2013 10:04, schrieb Tim Streater:

> In article <510F6570...@arnowelzel.de>,

> Arno Welzel <use...@arnowelzel.de> wrote:
>
>> crankypuss, 2013-02-02 21:27:
>>
>> [...]
>> > Is there a forum where the other folks (presuming there are any) who
>> > have been writing applications in PHP hang out? Don't say "yeah dummy,
>> > go to comp.lang.python" please, my homor quotient is maxed out for
>> > today. <g>
>>
>> Maybe <http://gtk.php.net/> is what you are looking for.
>

> Website hasn't been updated for three years.

I know - but this is everything i'm aware of for building "standalone"
applications with a GUI. If you can recommend something better - feel
free to do so. Maybe the OP will understand, why using PHP for this
purpose is not the best idea ;-)

[crankypuss]

I guess you never worked much with state-driven applications, not
everyone has. What we think of as a "desktop app" just sits there with
its state-data in memory, and a "web app" reloads its state-data when
another request comes in from the same user. Once the state data is
re-established the internal processing is basically the same except for
what subroutines are used to draw the "screen". In fact a "desktop app"
doesn't keep its state-data in memory except conceptually unless the
system is so lightly loaded that there's no thread-switching or swapping
going on. Conceptually it generalizes to pretty much the same thing in
either case.

The "message loop" you speak of really isn't any different between a
web-app and a desktop-app. For a desktop-app it looks like this,

1. application is entered on initiation
2. application presents initial display
4. application waits for input and is swapped out
5. user does something to cause an interrupt
6. application gets rescheduled as ready-to-run, swapped in
7. application scratches head, presents output
8. application goes back to (4) and gets "swapped out" again

For a web-app it looks like this,

1. server starts up and eventually reaches idle state
2. a message comes in (analogous to 5 above)
3. application's state data gets reloaded as it's "swapped in"
4. application scratches head, presents output
5. application gets swapped out (state saved)

It's pretty much the same thing, except that some websites don't do
squat about saving state-data for an individual user. Some use PHP
"session" stuff to do that, where a session identifier is a token coming
in on each http request that allows that user's state-data to be
reloaded for the request.

The loop is basically the same except that its "top" gets rolled around
to the middle and given a different name. For a desktop-app the "top"
is the guy hitting the enter key or clicking the mouse or whatever,
that's the top of the "message loop". For a web-app the browser
recognizes a link-click and sends an http request. It's the same thing
unless you get fixated on the details to the point where you can't see
the forest. Look an X Windows application in enough detail and you'll
see the same basic process with a different protocol used between the
client and the server. Steak or hamburger, it's all beef.

[crankypuss]

On 02/04/2013 12:40 AM, Arno Welzel wrote:
> crankypuss, 2013-02-03 11:49:
>
>> On 02/02/2013 02:27 PM, Jonathan N. Little wrote:
> [...]
>>> Because for the web is where PHP originated. Get data, do something,
>>> done. Not really suited for event driven apps.
>>
>> I have code that says you're mistaken.
>
> In which way? How does your PHP code handle events without polling in an
> endless loop?
>
>

There's only two ways to handle repetitive events, interrupts and
polling. No modern operating system polls by using a hard spin-loop,
and no application that isn't a total piece of crap ever implements a
hard spin-loop without some kind of system-call that allows it to be set
aside while the processor services another thread. Whether your
application contains a loop that has a system-call in it, or is
rescheduled when an interrupt comes in, it's the same loop with its top
rolled around and a different subroutine used to put it to sleep. Hell,
even if your application is so stupid that it's just branching to here,
any modern operating system will time-swap it out and let somebody else
have a shot at the processor.

So the answer depends somewhat on how one interprets "even driven". All
applications are event driven unless they are just doing hard
computation, in/grind/out. The techniques one uses to make the
application do what's intended vary depending on details. In other
words it depends on what you want to do. Polling is not bad if done
properly, neither are interrupt-based mechanisms, look close enough and
they're basically the same thing.

As for PHP being "not really suited for event driven apps" that seems
kind of silly to me, but then most people think that calling ncurses to
get a character means their application will have to sit there waiting
until the ENTER key is pressed. Sure, the ncurses call is blocking, but
that doesn't mean you can't write a non-blocking subroutine that does
something that's blocking; only threads get blocked, big deal.

[crankypuss]

Go to a line-mode login and try to run one of your Qt applications.

[crankypuss]

Maybe the OP will understand that his ncurses-based applications work
whether X is started or not. The OP has looked and grasps the idea that
Qt and Gtk require an X server. And the OP has written sufficient GUI
code in C++ to recognize a crap interface when he sees one. But thanks,
you appeared to be trying to help, and that's appreciated.

[crankypuss]

On 02/04/2013 02:34 AM, Tim Streater wrote:
> In article <kenv1g$ich$1...@dont-email.me>,

> Arno Welzel <use...@arnowelzel.de> wrote:
>
>> Am 04.02.2013 10:04, schrieb Tim Streater:
>>
>> > In article <510F6570...@arnowelzel.de>,
>> > Arno Welzel <use...@arnowelzel.de> wrote:
>> >
>> >> crankypuss, 2013-02-02 21:27:
>> >>
>> >> [...]
>> >> > Is there a forum where the other folks (presuming there are any) who
>> >> > have been writing applications in PHP hang out? Don't say "yeah
>> dummy,
>> >> > go to comp.lang.python" please, my homor quotient is maxed out for
>> >> > today. <g>
>> >>
>> >> Maybe <http://gtk.php.net/> is what you are looking for.
>> >
>> > Website hasn't been updated for three years.
>>
>> I know - but this is everything i'm aware of for building "standalone"
>> applications with a GUI. If you can recommend something better - feel
>> free to do so. Maybe the OP will understand, why using PHP for this
>> purpose is not the best idea ;-)
>

> I can't, unfortunately, I've been waiting for the gtk stuff myself for 6
> or 7 years.
>
> That doesn't stop me writing scripts in PHP. Neither does it stop me
> writing applications where I do the GUI bit in Javascript and the
> backend stuff in PHP. Heavy? Sure, but who cares. That's why we have
> multi-core, multi-GHz CPUs.
>

Yep. With almost any desktop application you can imagine, unless it's
written *very* poorly, the amount of time spent waiting for the user to
do something is a couple orders of magnitude larger than the time spent
actually doing processing. Desktop applications are only serving one
user and he's as slow as a human, it's different from a server
supporting a zillion requests from all and sundry.

[Jasen Betts]

On 2013-02-03, J.O. Aho <us...@example.net> wrote:

> On 03/02/13 12:50, The Natural Philosopher wrote:
>
>>> If you want something cross-platform, then look at mono, sure it's
>>> larger to install than PHP, but the benefit is that you can make
>>> applications that will run on multiple platforms.
>>>
>> java is probably the most popular cross platform interpreted language.
>>
>>

> Sure it is, but also the one which has been struggling with security
> issues and do not feel to be something to recommend nowadays, but lets
> see if Oracle has the will to fix the issues.

Simple. don't use Oracle Java. use one of the other two (or more?) flavours.

> I have to say I feel C# applications on Linux to be smother than Java,
> but then I don't use much of either.

yeah, half the cross platform stuff I use runs under Mono,
a third under Java and the rest is written in one of the oldest
cross-platform languages of all: C.

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Jasen Betts]

On 2013-02-03, M. Strobel <sorry_no_...@nowhere.dee> wrote:
> Am 03.02.2013 14:08, schrieb J G Miller:
>> On Sunday, February 3rd, 2013, at 10:58:04h +0100, M. Strobel wrote:
>>
>>> But in system administration the bash is the shell that starts Linux up.
>>
>> Most of the major distributions do not use bash as the startup shell,
>> but dash to provide a Bourne shell (not Bourne Again shell).
>>
>
> And in which distributions /bin/sh is not a link to /bin/bash?

dash is a debian thing (in name atleast),
it's used on debian and probably most of the ".deb" distros.

[Jasen Betts]

On 2013-02-03, The Natural Philosopher <t...@invalid.invalid> wrote:
> On 03/02/13 21:47, J G Miller wrote:

>> Well Debianistas do not always follow their own recommendations,
>> do they? ;)
>>
>> {init.d/}# ls -1 | wc -l
>> 120
>>
>> {init.d/}# grep bash *
>> acpi-support:#!/bin/bash
>> console-log:#! /bin/bash
>> nfs-kernel-server:#!/bin/bash
>>
>> {init.d}# grep '#! */bin/sh' * | wc -l
>> 120
>>
> That's amazing! 120-3 = 120!
>

no, that'd be /etc/init.d/README and other files with matching
strings on lines other than the first.

[Jasen Betts]

On 2013-02-03, crankypuss <noe...@noemail.invalid> wrote:
> On 02/02/2013 03:20 PM, Keith D. Lee wrote:
>> All:
>> What about Perl?
>>
>
> Enjoy. No reason not to go back to the predecessor of PHP. That's
> where PHP came from, y'know.

php.net says some feaures were inspired by perl.

> Some fellow whose name I don't recall
> built it to do the things Perl wasn't set up for. google "PHP history"
> there's a bit in wikipedia about it.

That's no more "coming from perl" that what I write here is "coming
from Crankypuss"

[crankypuss]

On 02/04/2013 05:23 AM, Jasen Betts wrote:
> On 2013-02-03, crankypuss <noe...@noemail.invalid> wrote:
>> On 02/02/2013 03:20 PM, Keith D. Lee wrote:
>>> All:
>>> What about Perl?
>>>
>>
>> Enjoy. No reason not to go back to the predecessor of PHP. That's
>> where PHP came from, y'know.
>
> php.net says some feaures were inspired by perl.
>
>> Some fellow whose name I don't recall
>> built it to do the things Perl wasn't set up for. google "PHP history"
>> there's a bit in wikipedia about it.
>
> That's no more "coming from perl" that what I write here is "coming
> from Crankypuss"
>

Wikipedia, the encyclopedia anyone can edit.

[Jonathan N. Little]

Well sort of, where the web app has a web server in between and the
desktop has the OS,

>
> 1. application is entered on initiation
> 2. application presents initial display
> 4. application waits for input and is swapped out
> 5. user does something to cause an interrupt
> 6. application gets rescheduled as ready-to-run, swapped in
> 7. application scratches head, presents output
> 8. application goes back to (4) and gets "swapped out" again
>
> For a web-app it looks like this,
>
> 1. server starts up and eventually reaches idle state
> 2. a message comes in (analogous to 5 above)
> 3. application's state data gets reloaded as it's "swapped in"
> 4. application scratches head, presents output
> 5. application gets swapped out (state saved)
>

However with the desktop app it keeps running with a pid to the
instance, the web app does not. To keep continuity with a web app you
need to employ session mechanism. It need some sort of a login and
logout or it gets quite complicated with DBs and files. A simple example:

Application updated a simple file from user:

Desktop
1. App launches get pid
2. Locks file.
3. Reads file.
4. Displays file.
5. Waits for user input.
6. Writes updated file.
7. Removes lock
8. Program exits and pid is destroyed

Web:
1. Session created with user login
2) Web server calls script
locks file*
reads it
displays it
script ends
3) Web server waits for next request.
check session if same user goto 4 else 2
4) Get user edits
write file
remove lock*
script ends
5) User logout to remove session

*With a web app you would not lock the file from step 2-4 because if the
user left (close the browser, whatever) the session does not
automatically get destroyed the the desktop pid to run a cleanup to
unlock the file and such. You can have a session expire to auto logout
and such but it is not the same at all. With a desktop app it is real
easy to to insure only one instance, not so nor often desirable for web.

> It's pretty much the same thing, except that some websites don't do
> squat about saving state-data for an individual user. Some use PHP
> "session" stuff to do that, where a session identifier is a token coming
> in on each http request that allows that user's state-data to be
> reloaded for the request.

To emulate what happens in the desktop environment on the web is not so
easy.

> The loop is basically the same except that its "top" gets rolled around
> to the middle and given a different name. For a desktop-app the "top"
> is the guy hitting the enter key or clicking the mouse or whatever,
> that's the top of the "message loop". For a web-app the browser
> recognizes a link-click and sends an http request. It's the same thing
> unless you get fixated on the details to the point where you can't see
> the forest. Look an X Windows application in enough detail and you'll
> see the same basic process with a different protocol used between the
> client and the server. Steak or hamburger, it's all beef.
>

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[crankypuss]

On 02/04/2013 02:29 AM, Arno Welzel wrote:

Sometimes it's hard for me to grasp the idea that most people just use
whatever is sitting on the shelf and would never consider the idea of
building something else; usually it's at least as difficult for them to
grasp the idea that for me applications are not half as interesting as
the tools that enable them. See, I don't *care* what's available this
week for writing standalone apps under PHP, what I mostly care about is
what the underlying operating system will support reliably and what the
PHP language itself is capable of.

The original post didn't ask for someone to help a poor weenie build
desktop applications in PHP, it asked who else is writing Linux or
cross-system applications in PHP, with perhaps some hope of finding out
where they're discussing it.

So far the answer is "no, we're using stuff we think is easier" with the
possibility that M. Strobel is also engaged in this bizarre activity
(though he didn't say yea or nay but commented on its applicability).

[crankypuss]

On 02/04/2013 09:06 AM, Jonathan N. Little wrote:

<mostly, snipped>

> To emulate what happens in the desktop environment on the web is not so
> easy.

The world is in a sad state when people prefer code that was written
easy over code that was written right.

[M. Strobel]

Am 03.02.2013 22:47, schrieb J G Miller:

> On Sunday, February 3rd, 2013, at 20:25:39h +0000, Richard Kettlewell wrote:
>
>> Neither of those pages contain instructions to avoid Bash.
>
> But this tends to suggest that bash should be avoided if possible.
>
> From <http://www.debian.org/doc/debian-policy/ch-files.html>
>
> QUOTE
>
> You may wish to restrict your script to SUSv3 features plus the above set when
> possible so that it may use /bin/sh as its interpreter. Checking your script
> with checkbashisms from the devscripts package or running your script with an
> alternate shell such as posh may help uncover violations of the above requirements.
> If in doubt whether a script complies with these requirements, use /bin/bash.
>
> UNQUOTE
>

>> Notice for instance that (at least in sid) dash.preinst is a #!/bin/bash
>> script, but dash doesn’t appear on the lintian page.
>

> Well Debianistas do not always follow their own recommendations,
> do they? ;)
>
> {init.d/}# ls -1 | wc -l
> 120
>
> {init.d/}# grep bash *
> acpi-support:#!/bin/bash
> console-log:#! /bin/bash
> nfs-kernel-server:#!/bin/bash
>
> {init.d}# grep '#! */bin/sh' * | wc -l
> 120
>

In archlinux all 47 scripts in /etc/rc.d are bash scripts.

In suse 11.4 /etc/init.d (and subdirs) I count 273 /bin/sh and 75 /bin/bash

I never had true Debian because of their conservatism.

/Str.

[The Natural Philosopher]

well there you go. You had better start from scratch and design your own
hardware then. And your own language and your own operating system.

Engineering is never about Getting Things Right: only mathematicians
have that luxury. For people in the Real World (TM) its a question of
getting things good enough for purpose, by the shortest and least hard
route.

If that means engineering a 1501cc engine in, instead of 1500cc, because
the difficulties of achieving the prefect Roundness of Wheels is
absolute, then that's what we do.

PHP is that route for simple web based apps. For anything else its
largely not that useful.

Accept it, and move on..

[The Natural Philosopher]

my debian server shows one instance of /bin/bash, and that's mysql startup.

All the rest are /bin/sh...

[M. Strobel]

Am 04.02.2013 17:08, schrieb crankypuss:

> Sometimes it's hard for me to grasp the idea that most people just use whatever is
> sitting on the shelf and would never consider the idea of building something else;
> usually it's at least as difficult for them to grasp the idea that for me
> applications are not half as interesting as the tools that enable them. See, I don't
> *care* what's available this week for writing standalone apps under PHP, what I
> mostly care about is what the underlying operating system will support reliably and
> what the PHP language itself is capable of.
>
> The original post didn't ask for someone to help a poor weenie build desktop
> applications in PHP, it asked who else is writing Linux or cross-system applications
> in PHP, with perhaps some hope of finding out where they're discussing it.
>
> So far the answer is "no, we're using stuff we think is easier" with the possibility
> that M. Strobel is also engaged in this bizarre activity (though he didn't say yea or
> nay but commented on its applicability).

I meant to say you could do it in PHP (build desktop applications), but nobody does
it because of how things evolved.

I am using Tcl/Tk for the desktop and for helpers to web applications, and PHP for
the web.

/Str.

[Jonathan N. Little]

The Natural Philosopher wrote:
> On 04/02/13 16:15, crankypuss wrote:
>> On 02/04/2013 09:06 AM, Jonathan N. Little wrote:
>>
>> <mostly, snipped>
>>
>>> To emulate what happens in the desktop environment on the web is not so
>>> easy.
>>
>> The world is in a sad state when people prefer code that was written
>> easy over code that was written right.
>
> well there you go. You had better start from scratch and design your own
> hardware then. And your own language and your own operating system.
>
> Engineering is never about Getting Things Right: only mathematicians
> have that luxury. For people in the Real World (TM) its a question of
> getting things good enough for purpose, by the shortest and least hard
> route.
>
> If that means engineering a 1501cc engine in, instead of 1500cc, because
> the difficulties of achieving the prefect Roundness of Wheels is
> absolute, then that's what we do.
>
> PHP is that route for simple web based apps. For anything else its
> largely not that useful.
>
> Accept it, and move on..
>

IOW the right tool for the right job.

[J G Miller]

On Monday, February 4th, 2013, at 16:24:43h +0000,

The Natural Philosopher wrote:

> Engineering is never about Getting Things Right

I would suggest that should be better stated as

"Engineering is never about Getting Things Perfect"

[M. Strobel]

... because perfect does not exist with contradictory requirements.

/Str.

[J G Miller]

On Monday, February 4th, 2013, at 09:08:21h -0700, Cranky Puss explained:

> The original post didn't ask for someone to help a poor weenie build
> desktop applications in PHP, it asked who else is writing Linux or
> cross-system applications in PHP, with perhaps some hope of finding out
> where they're discussing it.

It would be helpful if you could give some examples of what type
of applications you are in the processing of writing, as "Linux
application or cross-system application" is really so vague as to
be practically meaningless.

Why not post your question to newsgroup alt.php and see
if you get any answers?

[The Natural Philosopher]

...whiuch completely sums up so much.
Viz 'how can you assure me that (nuclear power stations, or any other
technology) is completely safe?

By not building it at all.

So no computers, cars electricity or anything. And by the way don't go
outside or the germs might get you, and don't stay indoors because its
also bad for you.


> /Str.

[Jasen Betts]

On 2013-02-04, Jonathan N. Little <lws...@gmail.com> wrote:
>
> However with the desktop app it keeps running with a pid to the
> instance, the web app does not. To keep continuity with a web app you
> need to employ session mechanism. It need some sort of a login and
> logout or it gets quite complicated with DBs and files. A simple example:

I did some experimetation wuth a web server that ran forked
applications and kept the instances around communicating with them via
pipes, it was neat seeing what were originally desktop apps running
over a browser on a server 700km away. development was abandonned.

>> It's pretty much the same thing, except that some websites don't do
>> squat about saving state-data for an individual user. Some use PHP
>> "session" stuff to do that, where a session identifier is a token coming
>> in on each http request that allows that user's state-data to be
>> reloaded for the request.

yeah there was cheking for that stuff...

> To emulate what happens in the desktop environment on the web is not so
> easy.

AJAX is a big help.

[crankypuss]

On 02/04/2013 09:24 AM, The Natural Philosopher wrote:
> On 04/02/13 16:15, crankypuss wrote:
>> On 02/04/2013 09:06 AM, Jonathan N. Little wrote:
>>
>> <mostly, snipped>
>>
>>> To emulate what happens in the desktop environment on the web is not so
>>> easy.
>>
>> The world is in a sad state when people prefer code that was written
>> easy over code that was written right.
>
> well there you go. You had better start from scratch and design your own
> hardware then. And your own language and your own operating system.

One never knows, do one. I'm not capable of designing my own hardware
from scratch at present, the rest I've done at one time or another.

> Engineering is never about Getting Things Right: only mathematicians
> have that luxury. For people in the Real World (TM) its a question of
> getting things good enough for purpose, by the shortest and least hard
> route.

Oddly enough the piece of paper they gave me back when dinosaurs roamed
the earth does not say anything about "Software Engineering" but it does
appear to grant me a halfassed degree in "Computer Science", and there
really is a difference.

> If that means engineering a 1501cc engine in, instead of 1500cc, because
> the difficulties of achieving the prefect Roundness of Wheels is
> absolute, then that's what we do.
>
> PHP is that route for simple web based apps. For anything else its
> largely not that useful.
>
> Accept it, and move on..
>

Take your own advice, son; I accepted it for many years, and I have
moved on.

[crankypuss]

PHP is hardly "the right tool" for any job, but it can be used for more
than simple web based apps.

[crankypuss]

... Jason Betts seems to be using PHP for desktop applications but
through a java front-end? And perhaps Tim Streater is doing something
with it too.

Not a whole huge mob of folks. <g>

[crankypuss]

On 02/04/2013 09:44 AM, J G Miller wrote:
> On Monday, February 4th, 2013, at 09:08:21h -0700, Cranky Puss explained:
>
>> The original post didn't ask for someone to help a poor weenie build
>> desktop applications in PHP, it asked who else is writing Linux or
>> cross-system applications in PHP, with perhaps some hope of finding out
>> where they're discussing it.
>
> It would be helpful if you could give some examples of what type
> of applications you are in the processing of writing, as "Linux
> application or cross-system application" is really so vague as to
> be practically meaningless.

The two applications that are furthest progressed are a partition-backup
utility and a boot-setup utility. Both of these are for Linux rather
than being cross-system. The only cross-system application I've written
in PHP so far is an accounting application for small businesses, but it
hasn't even been looked at for a couple years at least.

Probably the next two I'll address will be a file-manager to replace
Nautilus et-al, and a text editor. Unless I hold to my earlier plan to
resolve the oops-wrong-includes situation, or do something entirely
different.

> Why not post your question to newsgroup alt.php and see
> if you get any answers?
>

I'll check with google groups to see if that one's active these days, a
few years back I tried subscribing to it and it was fairly dead. If
what you really meant was "why not go away" that will doubtless happen
once people stop responding to this thread.

[The Natural Philosopher]

On 05/02/13 09:21, crankypuss wrote:
> On 02/04/2013 09:24 AM, The Natural Philosopher wrote:
>> On 04/02/13 16:15, crankypuss wrote:
>>> On 02/04/2013 09:06 AM, Jonathan N. Little wrote:
>>>
>>> <mostly, snipped>
>>>
>>>> To emulate what happens in the desktop environment on the web is not so
>>>> easy.
>>>
>>> The world is in a sad state when people prefer code that was written
>>> easy over code that was written right.
>>
>> well there you go. You had better start from scratch and design your own
>> hardware then. And your own language and your own operating system.
>
> One never knows, do one. I'm not capable of designing my own hardware
> from scratch at present, the rest I've done at one time or another.
>
>> Engineering is never about Getting Things Right: only mathematicians
>> have that luxury. For people in the Real World (TM) its a question of
>> getting things good enough for purpose, by the shortest and least hard
>> route.
>
> Oddly enough the piece of paper they gave me back when dinosaurs roamed
> the earth does not say anything about "Software Engineering" but it does
> appear to grant me a halfassed degree in "Computer Science", and there
> really is a difference.
>

I know. I've employed both. The one I sacked was a computer scientist.

>> If that means engineering a 1501cc engine in, instead of 1500cc, because
>> the difficulties of achieving the prefect Roundness of Wheels is
>> absolute, then that's what we do.
>>
>> PHP is that route for simple web based apps. For anything else its
>> largely not that useful.
>>
>> Accept it, and move on..
>>
>
> Take your own advice, son; I accepted it for many years, and I have
> moved on.

[The Natural Philosopher]

"With additional hardware and software, you *can* use an Apple II to
send a man to the moon"

[Arno Welzel]

Tim Streater, 2013-02-05 11:31:

> In article <keqj7...@news3.newsguy.com>,

> crankypuss <noe...@noemail.invalid> wrote:
>
>> ... Jason Betts seems to be using PHP for desktop applications but
>> through a java front-end? And perhaps Tim Streater is doing something
>> with it too.
>

> My desktop app uses JavaScript to present to the user, and PHP for
> backend stuff such as writing to SQLite databases, communicating over
> the net, writing log files, and other functions that the app needs. I
> use apache/ajax to communicate between the two. As I said before -
> heavy? Sure, but who cares.

I would care if i would need all that stuff just to be able to run an
application. It's not only about processing power or memory consumption
- but also about security and stability. The more components you put
together the more likely something can go wrong.


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[Arno Welzel]

crankypuss, 2013-02-04 10:55:

> On 02/04/2013 12:38 AM, Arno Welzel wrote:
>> crankypuss, 2013-02-02 21:27:
>>
>> [...]
>>> Is there a forum where the other folks (presuming there are any) who
>>> have been writing applications in PHP hang out? Don't say "yeah dummy,
>>> go to comp.lang.python" please, my homor quotient is maxed out for
>>> today. <g>
>>
>> Maybe <http://gtk.php.net/> is what you are looking for.
>>

>> But this is still very limited - i recommend to learn C++ and how to use
>> Qt. See <http://qt-project.org/downloads>.
>>
>> Qt also provides "Qt Creator" - a nice IDE including GUI designer,
>> debugger etc.. (see
>> <http://qt-project.org/wiki/Category:Tools::QtCreator>).
>>
>>
>
> Go to a line-mode login and try to run one of your Qt applications.

<http://doc.qt.digia.com/solutions/4/qtsingleapplication/qtsinglecoreapplication-example-console.html>

[Arno Welzel]

crankypuss, 2013-02-04 10:32:

[...]

> The loop is basically the same except that its "top" gets rolled around
> to the middle and given a different name. For a desktop-app the "top"
> is the guy hitting the enter key or clicking the mouse or whatever,
> that's the top of the "message loop". For a web-app the browser
> recognizes a link-click and sends an http request. It's the same thing
> unless you get fixated on the details to the point where you can't see
> the forest. Look an X Windows application in enough detail and you'll
> see the same basic process with a different protocol used between the
> client and the server. Steak or hamburger, it's all beef.

If you're a hammer every problem is just a nail...

[Arno Welzel]

crankypuss, 2013-02-03 12:13:

> On 02/02/2013 03:20 PM, Keith D. Lee wrote:
>> All:
>> What about Perl?
>>
>
> Enjoy. No reason not to go back to the predecessor of PHP. That's
> where PHP came from, y'know. Some fellow whose name I don't recall
> built it to do the things Perl wasn't set up for. google "PHP history"
> there's a bit in wikipedia about it.

Ahem - no, PHP did not come from Perl.

Read the original source, not Google or Wikipedia:
<http://www.php.net/manual/en/history.php.php>

PHP took some ideas from Perl but originally PHP was just a set of CGI
tools which had nothing to do with Perl at all.

[Arno Welzel]

crankypuss, 2013-02-04 16:57:

> On 02/04/2013 05:23 AM, Jasen Betts wrote:

>> On 2013-02-03, crankypuss <noe...@noemail.invalid> wrote:
>>> On 02/02/2013 03:20 PM, Keith D. Lee wrote:
>>>> All:
>>>> What about Perl?
>>>>
>>>
>>> Enjoy. No reason not to go back to the predecessor of PHP. That's
>>> where PHP came from, y'know.
>>

>> php.net says some feaures were inspired by perl.

>>
>>> Some fellow whose name I don't recall
>>> built it to do the things Perl wasn't set up for. google "PHP history"
>>> there's a bit in wikipedia about it.
>>

>> That's no more "coming from perl" that what I write here is "coming
>> from Crankypuss"
>>
>
> Wikipedia, the encyclopedia anyone can edit.

I just corrected this part in Wikipedia, since none of the cited sources
refer to Perl at all - PHP was a set of binary tools written in C. They
had nothing to do with Perl at all except some ideas for the syntax for
the interpreter.

[Arno Welzel]

Tim Streater, 2013-02-05 13:56:

> In article <5110FDFB...@arnowelzel.de>,
> Arno Welzel <use...@arnowelzel.de> wrote:
>
[...]

>> > My desktop app uses JavaScript to present to the user, and PHP for
>> > backend stuff such as writing to SQLite databases, communicating over
>> > the net, writing log files, and other functions that the app needs. I
>> > use apache/ajax to communicate between the two. As I said before -
>> > heavy? Sure, but who cares.
>>
>> I would care if i would need all that stuff just to be able to run an
>> application. It's not only about processing power or memory consumption
>> - but also about security and stability. The more components you put
>> together the more likely something can go wrong.
>

> Look, here's a bar magnet and a magnifying glass. Now you can edit the
> bits directly on the disk, no need for any software components at all.
> Happy now?

You don't get it or you never wrote an application which you made
available to the public.

[Jerry Stuckle]

Well said, Arno!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================

[Cybe R. Wizard]

On Tue, 05 Feb 2013 13:49:55 +0100
Arno Welzel <use...@arnowelzel.de> wrote:

> If you're a hammer every problem is just a nail...

I heard that as, "if all you have is a hammer every job looks like a
thumb."

Cybe R. Wizard
--
Registered GNU/Linux user # 126326
Registered Ubuntu User # 2136-deprecated

[J G Miller]

On Tuesday, February 5th, 2013, at 02:36:24h -0700, Cranky Puss explained:

> The two applications that are furthest progressed are a partition-backup
> utility and a boot-setup utility.

Thank you for the clarification in providing the details.

I rather curious as what you mean by boot-setup utility though.
Do you mean a replacement for GRUB or something that configures
grub? Or something that configures the contents of initramfs
or something that configures sysVinit/upstart/systemd?

> I'll check with google groups to see if that one's active these days

Why Google groups? You have a newsreader do you not and a quick
visit with that to alt.php shews that there are some recent posts
and discussion (not a lot but some).

> If what you really meant was "why not go away"

I have never told anybody on Usenet to go away. I may have
inferred to some "quit whining with the same stuck in the
groove needle" (because it does get tiresome after a while),
but never go away.

In fact I would suggest that those postings with contrary views
generate the most discussion, and provided that they do not
descend into flames and personal abuse, are sometimes quite
informative.

> that will doubtless happen once people stop responding to this thread.

Apart from spam and troll postings (neither of which applies to
your postings) that is the best way to kill Usenet discussion.

[crankypuss]

You know, regardless of my 'nym, I try to get along with folks. You
however seem to be the type of fellow that makes my teeth grind, the
type that just does what he's told and tells others to do the same, the
type of person who would, given his druthers, impede all progress in
order to maintain the position his ego tells him he holds. You and all
the others like you who just take whatever happens to be on the shelf
and use it as best they can to write the best software they can, which
usually happens to be garbage because they're basing it on garbage,
well, you are obsolete imo.


"All the Linux community wants is to create a really good,
fully-featured, free operating system. If that results in Linux becoming
a hugely popular OS, then that's great. If that results in Linux having
the most intuitive, user-friendly interface ever created, then that's
great. If that results in Linux becoming the basis of a multi-billion
dollar industry, then that's great.

It's great, but it's not the point. The point is to make Linux the best
OS that the community is capable of making. Not for other people: For
itself."
http://linux.oneandoneis2.org/LNW.htm

[crankypuss]

On 02/05/2013 05:15 AM, The Natural Philosopher wrote:
> I know. I've employed both. The one I sacked was a computer scientist.

Well you're really hot shit, fucktard; I retired out from under a bunch
of morons just like you who are still contributing their portion of shit
to the world toilet while I am off building the software that I see a
need for. Keep on doing what you're told with the tools you're told to
use, it's all you're barely capable of.

[crankypuss]

On 02/05/2013 08:03 AM, J G Miller wrote:
> On Tuesday, February 5th, 2013, at 02:36:24h -0700, Cranky Puss explained:
>
>> The two applications that are furthest progressed are a partition-backup
>> utility and a boot-setup utility.
>
> Thank you for the clarification in providing the details.
>
> I rather curious as what you mean by boot-setup utility though.
> Do you mean a replacement for GRUB or something that configures
> grub? Or something that configures the contents of initramfs
> or something that configures sysVinit/upstart/systemd?

There used to be a tool called "grub-customizer". I started using it a
year or so ago. A few months back it seemed to go down the tubes. It
added support for burg and basically turned into a random-config-generator.

What I'm building is a replacement for it, something more general and
somewhat simpler. Currently it only supports grub-2 to a limited
extent, it doesn't yet allow specification of most of the available
parameters, but it does generate a working config which is more than I
can say for grub-customizer when I uninstalled it. Eventually it's
likely to support grub-legacy and maybe lilo and whatever, there's no
conceptual reason that can't be done. It just flat ignores whatever
happens to be in /etc/grub.d/ and builds a /boot/grub/grub.cfg file from
your specifications; it saves the abstracted information about the boot
setup in an xml file in root so you don't have to specify everything
every time. I've been using it for a couple months now and it does the
job; when you run it, it brings up a list of all your bootable
partitions, and lets you walk through a few menus to specify your boot
config. Those who are happy dicking around with /etc/grub.d/ probably
wouldn't like it at all, but it does leave /etc/grub.d/ in whatever
shambles it was in before it was used.

[crankypuss]

If you're using other people's components that's basically true, though
the likelihood of a problem doesn't increase in direct proportion to the
number of "foreign" components you're using but in relation to their
quality... which of course is guesswork unless it's something like Adobe
Flash which you can pretty much bet is messed up somehow.

[crankypuss]

I used to make some stuff available to others, and I've used more cuss
words on other people's components than anything else... for that matter
I've yet to find an operating system that I can really trust over the
long haul, application code keeps having to implement workaround after
workaround to counteract changes in successive releases. I remember
some gawdawful conditional assembler code to make some stuff that should
have been pretty simple just keep working as the system interfaces
shifted around under it like jello.

Sometimes I think "what the world needs" (or at least, what I'd like to
have a copy of) is a Linux distro called LCDlinux (for Lowest Common
Denominator) so an LCD could actually be *established* and then improved
at the system level. (And no, its name ain't "slackware" as far as I
can tell.) I don't think I've seen a really clean set of system
interfaces since CP/M or maybe OS/360, "modern" interfaces seem designed
to make it easy for system developers, or perhaps tg maximize the amount
of hoop-jumping on the part of application developers.

Meanwhile the idea of distributing any of my PHP applications gives me
the shudders because of the dozens of includes and hundreds of
subroutines all needing to be in the right directories and so forth.
One of these days I'll go back and rework some parsing code I built
while doing web-apps and use it to collect all the subroutines into a
single file, or better yet gzip them and embed the compressed source in
a tweaked-up copy of the PHP interpreter so that an application consists
of one binary file.

Sometimes I would damn near take the bar magnet and magnifying glass
just so I'd have something to work with that could actually be counted
on, when you key the program in through the dip-switches at least you
know what you have.

[crankypuss]

Thanks for the link. It's potentially interesting, but the OOP obscura
kind of hides what it's doing. Presumably you've run it on a line-mode
console? What level of support does it provide, is it character mode or
pixel mode? What are they using for their interface to the display?

[J G Miller]

On Tuesday, February 5th, 2013, at 12:24:38h -0700, Cranky Puss complained:

> I've yet to find an operating system that I can really trust over the
> long haul

I keep mentioning OpenBSD to you, but have you looked at it?

<http://www.openbsd.ORG/>

If one cannot trust FreeBSD, what can one trust?

See in particular

<http://www.openbsd.ORG/goals.html>

[J G Miller]

On Tuesday, February 5th, 2013, at 12:07:47h -0700, Cranky Puss explained:

> Currently it only supports grub-2 to a limited extent, it doesn't yet
> allow specification of most of the available parameters, but it does
> generate a working config which is more than I can say for grub-customizer
> when I uninstalled it.

Okay I follow, but does it successfully auto probe for all the different
OSes which may be present on all of the different file systems?

> but it does leave /etc/grub.d/ in whatever shambles it was in before
> it was used.

grub.d is certainly an abomination and each distribution makes it worse,
notably the chain debian -> ubuntu -> mint

Want to add another item, then the config script has to tail itself
on to the configuration, eg my just added plop_40

#!/bin/sh

exec tail -n +4 $0

menuentry "Plop Boot Manager" {
set root=(hd0,6)
linux16 /plop-boot-image
}

[The Natural Philosopher]

No, I am just a person who had to produce results to acceptable costs in
acceptable timescales.

Something they don't teach computer scientists.

[The Natural Philosopher]

No one tells me what tools to use.

I have the luxury of being able to choose the ones that suit the job to
be done.

[Jasen Betts]

On 2013-02-05, crankypuss <noe...@noemail.invalid> wrote:
>> where they're discussing it.
>>

>> So far the answer is "no, we're using stuff we think is easier" with the
>> possibility that M. Strobel is also engaged in this bizarre activity
>> (though he didn't say yea or nay but commented on its applicability).

>
> ... Jason Betts seems to be using PHP for desktop applications but
> through a java front-end? And perhaps Tim Streater is doing something
> with it too.
>

> Not a whole huge mob of folks. <g>

Nah, it's all C and and a little javascript at the client end.

I php for websites, and Im starting to regret it.

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Jasen Betts]

On 2013-02-05, crankypuss <noe...@noemail.invalid> wrote:

> What I'm building is a replacement for it, something more general and
> somewhat simpler. Currently it only supports grub-2 to a limited
> extent, it doesn't yet allow specification of most of the available
> parameters, but it does generate a working config which is more than I
> can say for grub-customizer when I uninstalled it. Eventually it's
> likely to support grub-legacy and maybe lilo and whatever, there's no
> conceptual reason that can't be done. It just flat ignores whatever
> happens to be in /etc/grub.d/ and builds a /boot/grub/grub.cfg file from
> your specifications; it saves the abstracted information about the boot
> setup in an xml file in root so you don't have to specify everything
> every time. I've been using it for a couple months now and it does the
> job; when you run it, it brings up a list of all your bootable
> partitions, and lets you walk through a few menus to specify your boot
> config. Those who are happy dicking around with /etc/grub.d/ probably
> wouldn't like it at all, but it does leave /etc/grub.d/ in whatever
> shambles it was in before it was used.

I think /etc/grub.d is what lets me install memtest86 without editing
any config files, it's purpose is to allow pluggable componets without
groping through config files. a task it achieves well. possibly it's a
debian thing

they did the same to init, cron, logrotate, exim, apache ...

trying to fight it is probably going to be counter-productive

[Jasen Betts]

I think the idea is to make packaging stuff easier.
by making the fragments executable they allow maximum compile-time
capability without much work.

if you're happy to write a customised configuation file after
installing the software then grub.d isn't for you, if on the other
hand you just want it to work it's a neat invention.



--
⚂⚃ 100% natural