What exactly is more powerful and less fragile about Python in comparison to a sh script?
If you are serious, you need to freshen up your computing skills a little bit. Shell scripts tend to fail in unpredictable ways, often with no clue what went wrong. Python script raises an exception that immediately tells where the problem is.
Programming languages are for writing programs to do things, sh scripts are for tying things together in an automated way.
You don't realize that things have changed from the time sh was developed. Better languages for the job exist now. Some of us can recognize superior technology - others repeat obsolete tautologies like mantras, with zero understanding of technological realities.
Python is a nightmare to do nearly anything complex with for me.
I'm not sure what that sentence means.
It requires way too many dependencies, is less reliable than good old "${SHELL}", and typically requires more overhead from my CPU and memory.
I'm not sure what kind of boxen you work with, but they certainly sound pretty broken and underpowered. Buy some p5, they should go for pretty low prices these days and have enough power to run these "heavy" tools.
Happy New Year, troll.
I think this underlines your mentality. Mod down and flame, instead of sticking to technical issues. The technical points you present sound pretty childish to me, and showcase a profound lack of understanding of the issues involved w/ complex systems. You should really catch up w/ the times, or be buried w/ the obsolete Unix boxen you currently maintain.
BTW, if I notice something postworthy I post w/ my real name and skip moderation. Disagreeing with someone doesn't mean it's a troll.
Which is the reason why Python comes with a ~20000-line configure script written in sh,
Techically it's not 'written', it's an autoconf script.
Knowing shell scripting also helps when working in interactive mode, a loop or case/esac is also useful in one-liners.
This is true. Especially for loop comes in handy in interactive sessions.
Knowing shell scripts is good, even necessary for sysadmins. Writing shell scripts is what should be discouraged.
You can source shell scripts, hence you can write a shell script that modifies the environment of your interactive session. You cannot do that with any other language.
Right. This is one of the defendable reasons for using shell scripts. The other one is "shorcut"-like functionality, i.e. using the script as an alias for a program w/ some arguments, perhaps changing the values of environment variables beforehand.
The shell is universally available. On some low-end systems (yes they still exist), Python and even Perl might not be installed.
Yes, of course. Yet most of the scripts that sysadmins write are for normal systems with no such limitations.
I'm not saying shell scripts have no purpose. I'm saying that in 95% of of the cases they are used a more structured solution would have been more appropriate.
For one thing, launching processes or manipulating the file system (which is the only reason for a scripting language) is going to be much more verbose in Python.
os.system("mycommand a.txt")
Python will make you do incredibly stupid and redundant things like open files.
How? Could you elaborate? You don't need to do anything you don't need with shell scripts.
Secondly, injecting a filter between pipes in Python means either reading in the input entirely (waste of memory), or reading it piecemeal (verbose and unnecessary). With the shell, you inject a sub-process.
os.system() allows you to execute full pipelines. I don't see what's the problem. You slurp in the output when you need to do something more advanced that can't be done by piping it to a pre-existing command.
When I really need a program I'll turn to Python or C, but 99% of the time when I just need to get something done grep, find and a knowledge of regular expressions does the trick.
Those can usually be done on a single pipeline. Some people insist on using multiline shell scripts to do the trick.
What's the point in writing scripts in sh anyway? These days you can use more powerful and less fragile languages like Python. Shells have crappy error handling, complex escaping rules and generally they create more problems than they solve.
In Python, you can easily read the contents of executing programs popen, and likewise write the processed output to other processes also via popen. More facilities exist for error handling, logging and other general "growth" paths of the scripts.
Choosing to write something over 4 lines in a shell scripting language (sh) is a sign of incomptence, nothing else. Sysadmin should still IMO be competent enough to grok more structured languages like Python. It's not the windows world after all...
Sysadmins should also be responsible enough to consider that someone might want to edit the script after him. Shell scripts tend to break w/ editing.
Moderators: reply instead of modding down. Tell us why someone should prefer a crippled language when more advanced (and still equally easy to use) technology still has uses. History alone doesn't warrant it.
UserLinux is IMHO taking the right road, in suggesting that scripts be written in Python.
Seems to me that paying $3000 up front is good business sense if it can save you tens of thousands of dollars in development cost compared to using an inferior more-free library.
That's a big if. And remember that the license cost is per developer, per annum. If the development spans multiple years (maintenance surely will), the cost can be pretty high.
Get over it, you were wrong. Linking non-GPL code to the kernel is common and it is a problem.
That was not the point. It's a problem for lots of *users*. A GPL'd library is a problem for lots of *companies* that develop software. Especially as there are several UI libraries w/ more free licenses around.
I can't figure why people scream about this (memory of the old licence situation maybe) and not about the kernel or GNU tools, those don't even give you the choice of paying for the closed option.
If/when changes are made to kernel or GNU tools (which is *extremely* rare in mainstream, non-embedded development) the changes are so minor that sharing them doesn't compromise the comptetitive position.
Qt, on the other hand, is a library. It's sole reason for existence is to be linked with applications that companies develop. See the difference?
We haven't decided what to replace them with yet (most likely RHEL AS or possibly Solaris - it has to be certified for Progress),
Well, if performance or future-proofness matter to you at all, pick up RHEL. Solaris is a dead end. BTW, I thought Progress was going to certify RHEL ES. What happened to that?
Go ahead and do it. Progress DB (and 4GL env) works very well in Linux. I had a role in switcing a Progress environment from HP-UXen to HP ProLiants, and it was easy and trouble-free. It will be even easier for you, since you can keep on running on the same HW.
Why on earth are you still running SCO, BTW? Do the machines carry some weird SW that is not found in Linux?
Using C for a base library has a number of nice side effects, like: 1. Not needing a C++ compiler
Who cares? gcc is here, and it has good C++ support now.
The rest of the stuff I mostly agree with. However, the Python bindings for Qt are generated from C++ code by Swig, so that they get the OO feel automatically. Seems like a good thing for me.
I know the difference between the library and application. But would you care to explain how does it affects my points or arguments ?
My point was that license is hugely important for something that the user might link to while w/ application it doesn't matter as long as it's "free enough".
As far as your other points go, look and feel are a "technical argument" in an end-user application like a browser.
The KDE proposal sugests that UL include both Qt and GTK libraries, it says nothing about trying to "port" KDE to GTK,
Well, they promise some kind of integration. I expected this to mean that Gtk apps will look like Qt apps in the future, if that is wanted.
Oh, who cares? If you want to develop and distribute closed source apps, why don't you do it on Windows?
So basically you are suggesting that Linux is only good for OSS apps? I tend to believe in the commercial success of Linux in the near future, my app might only be usefull in context of Linux, or the company I am writing my app to uses Linux on desktops.
In case you didn't notice, the Linux culture values freedom.
Perhaps you tried to write GNU/Hurd culture?
The freedom might be severely compromised if we don't get significant corporate backing (and subsequently, corporate dependency on Linux). Some big company (with more serious claims than SCO) might choose to squash Linux, and if we don't have lots of wealthy corporate users, we just might be screwed.
But now it seems KDE is more "free software" than GNOME is.
It's more RMS, not more free. GPL is not more free than e.g. LGPL or BSD, it's exactly the opposite.
The "Lesser" LGPL license lets you make proprietary software by screwing over free software developers and using their libraries without giving anything back to the community that provided the entire platform you are developing on.
It's in the interest of a library developer to have as many users as possible, proprietary or not. LGPL is in fact a recommended license for libraries, and GPL libs should be reserved for tasks where nothing else will do.
The idea of a UI toolkit is not to offer anything revolutionary that would warrant GPL - just to offer a standard useful API to do the obvious. If you can only use the API to do GPL applications, well, that sucks.
Well then, lets put it on the table. This project is not by or for the community. Yet it depends on the contributions of a huge number of developers.
When, oh when will people realize that the future of Linux and Open Source is dependent on corporate adoption? Bruce says it himself - widespread corporate adoption is necessary to combat the sw patent and other (idiotic) legal threats.
If the corps are not with us, they will be on the other side and we will lose.
Companies don't want to support multiple versions of Linux. Thus a single version is going to be what drives Linux in business.
There will be at least RHEL, SUSE, and now UL.
So much for Open Source ideals.
I don't see any conflict with OSS ideals. You are not forced to use UL, it's all Open Source, you can install whatever you want, you can install UL apps on other Linux platforms, etc.
Slashdot Mirror
What exactly is more powerful and less fragile about Python in comparison to a sh script?
If you are serious, you need to freshen up your computing skills a little bit. Shell scripts tend to fail in unpredictable ways, often with no clue what went wrong. Python script raises an exception that immediately tells where the problem is.
Programming languages are for writing programs to do things, sh scripts are for tying things together in an automated way.
You don't realize that things have changed from the time sh was developed. Better languages for the job exist now. Some of us can recognize superior technology - others repeat obsolete tautologies like mantras, with zero understanding of technological realities.
Python is a nightmare to do nearly anything complex with for me.
I'm not sure what that sentence means.
It requires way too many dependencies, is less reliable than good old "${SHELL}", and typically requires more overhead from my CPU and memory.
I'm not sure what kind of boxen you work with, but they certainly sound pretty broken and underpowered. Buy some p5, they should go for pretty low prices these days and have enough power to run these "heavy" tools.
Happy New Year, troll.
I think this underlines your mentality. Mod down and flame, instead of sticking to technical issues. The technical points you present sound pretty childish to me, and showcase a profound lack of understanding of the issues involved w/ complex systems. You should really catch up w/ the times, or be buried w/ the obsolete Unix boxen you currently maintain.
BTW, if I notice something postworthy I post w/ my real name and skip moderation. Disagreeing with someone doesn't mean it's a troll.
Which is the reason why Python comes with a ~20000-line configure script written in sh,
Techically it's not 'written', it's an autoconf script.
Knowing shell scripting also helps when working in interactive mode, a loop or case/esac is also useful in one-liners.
This is true. Especially for loop comes in handy in interactive sessions.
Knowing shell scripts is good, even necessary for sysadmins. Writing shell scripts is what should be discouraged.
You can source shell scripts, hence you can write a shell script that modifies the environment of your interactive session. You cannot do that with any other language.
Right. This is one of the defendable reasons for using shell scripts. The other one is "shorcut"-like functionality, i.e. using the script as an alias for a program w/ some arguments, perhaps changing the values of environment variables beforehand.
. In my experience there haven't been any more bugs/maintenance problems with 30 line shell scripts compared to 30 line perl scripts.
:-).
I think that says more about Perl than shell scripts
The shell is universally available. On some low-end systems (yes they still exist), Python and even Perl might not be installed.
Yes, of course. Yet most of the scripts that sysadmins write are for normal systems with no such limitations.
I'm not saying shell scripts have no purpose. I'm saying that in 95% of of the cases they are used a more structured solution would have been more appropriate.
For one thing, launching processes or manipulating the file system (which is the only reason for a scripting language) is going to be much more verbose in Python.
os.system("mycommand a.txt")
Python will make you do incredibly stupid and redundant things like open files.
How? Could you elaborate? You don't need to do anything you don't need with shell scripts.
Secondly, injecting a filter between pipes in Python means either reading in the input entirely (waste of memory), or reading it piecemeal (verbose and unnecessary). With the shell, you inject a sub-process.
os.system() allows you to execute full pipelines. I don't see what's the problem. You slurp in the output when you need to do something more advanced that can't be done by piping it to a pre-existing command.
When I really need a program I'll turn to Python or C, but 99% of the time when I just need to get something done grep, find and a knowledge of regular expressions does the trick.
Those can usually be done on a single pipeline. Some people insist on using multiline shell scripts to do the trick.
Tell us why someone should prefer a crippled language when more advanced (and still equally easy to use) technology *) still has uses.
*) is available.
It's new years eve, wine made me do the grammatcal/semantic error.
And thanks, anonymour moderator, for the "troll" moderation. Want to silence any discussion that touches too close to the home, right?
What's the point in writing scripts in sh anyway? These days you can use more powerful and less fragile languages like Python. Shells have crappy error handling, complex escaping rules and generally they create more problems than they solve.
In Python, you can easily read the contents of executing programs popen, and likewise write the processed output to other processes also via popen. More facilities exist for error handling, logging and other general "growth" paths of the scripts.
Choosing to write something over 4 lines in a shell scripting language (sh) is a sign of incomptence, nothing else. Sysadmin should still IMO be competent enough to grok more structured languages like Python. It's not the windows world after all...
Sysadmins should also be responsible enough to consider that someone might want to edit the script after him. Shell scripts tend to break w/ editing.
Moderators: reply instead of modding down. Tell us why someone should prefer a crippled language when more advanced (and still equally easy to use) technology still has uses. History alone doesn't warrant it.
UserLinux is IMHO taking the right road, in suggesting that scripts be written in Python.
Seems to me that paying $3000 up front is good business sense if it can save you tens of thousands of dollars in development cost compared to using an inferior more-free library.
That's a big if. And remember that the license cost is per developer, per annum. If the development spans multiple years (maintenance surely will), the cost can be pretty high.
Get over it, you were wrong. Linking non-GPL code to the kernel is common and it is a problem.
That was not the point. It's a problem for lots of *users*. A GPL'd library is a problem for lots of *companies* that develop software. Especially as there are several UI libraries w/ more free licenses around.
Come on, it can't be that hard to understand...
Extremely rare? Linking proprietary code to the kernel?
Have you been living in a cave, or have you not heard of proprietary drivers?
Drivers are typically written to enable the use of the kernel. Usually drivers are not the product itself.
I can't figure why people scream about this (memory of the old licence situation maybe) and not about the kernel or GNU tools, those don't even give you the choice of paying for the closed option.
If/when changes are made to kernel or GNU tools (which is *extremely* rare in mainstream, non-embedded development) the changes are so minor that sharing them doesn't compromise the comptetitive position.
Qt, on the other hand, is a library. It's sole reason for existence is to be linked with applications that companies develop. See the difference?
Nobody tries to hide the bias, it's one of the reasons the site is popular.
which will be accessible via Ms. Access using an ODBC driver from the clients.
Not answering your question here or anything, but you might want to check out Rekall if that Access code is not in place yet.
We haven't decided what to replace them with yet (most likely RHEL AS or possibly Solaris - it has to be certified for Progress),
Well, if performance or future-proofness matter to you at all, pick up RHEL. Solaris is a dead end. BTW, I thought Progress was going to certify RHEL ES. What happened to that?
We use and sell SCO to run progress db apps.
We have made plans to switch away from it.
Go ahead and do it. Progress DB (and 4GL env) works very well in Linux. I had a role in switcing a Progress environment from HP-UXen to HP ProLiants, and it was easy and trouble-free. It will be even easier for you, since you can keep on running on the same HW.
Why on earth are you still running SCO, BTW? Do the machines carry some weird SW that is not found in Linux?
I was almost taking the survey seriously until I saw those options.
They are in there so MSFT can, when publishing the results, claim that Linux users avoid Windows for "irrational" reasons.
Maybe. But the future of free software certainly doesn't depend on "corporate adoption".
Don't underestimate the power of stupid laws and US legal system.
And your point is?
Come on, drop the rhetoric, you got my point.
Using C for a base library has a number of nice side effects, like: 1. Not needing a C++ compiler
Who cares? gcc is here, and it has good C++ support now.
The rest of the stuff I mostly agree with. However, the Python bindings for Qt are generated from C++ code by Swig, so that they get the OO feel automatically. Seems like a good thing for me.
I know the difference between the library and application. But would you care to explain how does it affects my points or arguments ?
My point was that license is hugely important for something that the user might link to while w/ application it doesn't matter as long as it's "free enough".
As far as your other points go, look and feel are a "technical argument" in an end-user application like a browser.
Perhaps I am missing something.
Yes - you are missing the difference between a library and an application.
The KDE proposal sugests that UL include both Qt and GTK libraries, it says nothing about trying to "port" KDE to GTK,
Well, they promise some kind of integration. I expected this to mean that Gtk apps will look like Qt apps in the future, if that is wanted.
Oh, who cares? If you want to develop and distribute closed source apps, why don't you do it on Windows?
So basically you are suggesting that Linux is only good for OSS apps? I tend to believe in the commercial success of Linux in the near future, my app might only be usefull in context of Linux, or the company I am writing my app to uses Linux on desktops.
In case you didn't notice, the Linux culture values freedom.
Perhaps you tried to write GNU/Hurd culture?
The freedom might be severely compromised if we don't get significant corporate backing (and subsequently, corporate dependency on Linux). Some big company (with more serious claims than SCO) might choose to squash Linux, and if we don't have lots of wealthy corporate users, we just might be screwed.
But now it seems KDE is more "free software" than GNOME is.
It's more RMS, not more free. GPL is not more free than e.g. LGPL or BSD, it's exactly the opposite.
The "Lesser" LGPL license lets you make proprietary software by screwing over free software developers and using their libraries without giving anything back to the community that provided the entire platform you are developing on.
It's in the interest of a library developer to have as many users as possible, proprietary or not. LGPL is in fact a recommended license for libraries, and GPL libs should be reserved for tasks where nothing else will do.
The idea of a UI toolkit is not to offer anything revolutionary that would warrant GPL - just to offer a standard useful API to do the obvious. If you can only use the API to do GPL applications, well, that sucks.
Well then, lets put it on the table. This project is not by or for the community. Yet it depends on the contributions of a huge number of developers.
When, oh when will people realize that the future of Linux and Open Source is dependent on corporate adoption? Bruce says it himself - widespread corporate adoption is necessary to combat the sw patent and other (idiotic) legal threats.
If the corps are not with us, they will be on the other side and we will lose.
Companies don't want to support multiple versions of Linux. Thus a single version is going to be what drives Linux in business.
There will be at least RHEL, SUSE, and now UL.
So much for Open Source ideals.
I don't see any conflict with OSS ideals. You are not forced to use UL, it's all Open Source, you can install whatever you want, you can install UL apps on other Linux platforms, etc.