This is odd but absolutely true. Python "should" be easier to learn (and probably is) but bash (or Bourne) is so endemic to UNIX/Linux programming that anyone and everyone wanting to play with Linux system operation pushes themselves to learn the sometimes ungainly and painful bash syntax. I did, and I also learned C (for other reasons though). Later I worked hard to learn Python, and though it is an extremely easy to understand and read syntax, I nevertheless struggled terribly to get on top of it - as MU suggests earlier, for some bizarre reason my brain had become too used to the less than nice looking syntax of C and the way it almost exactly models the way data is used in UNIX. But that brings me to the following, which I don't agree with at all [EDIT: sorry... I do agree with DMcCunney to some extent afterall; see my next post]DMcCunney wrote: Whether it's more human readable is entirely a matter of whether you know the language. A lot of folks are proficient in Bourne shell scripting (and the bash script language is Bourne shell with extensions.) Less people are proficient in Python and TclTk.
Linux, as with modern UNIX, is written in C, though in some ways the relationship between C and UNIX is like the chicken and the egg scenario. It is as if C is written 'for' UNIX/Linux; it provides all the system calls and functionality to provide pipes and redirection. In many ways, all the bash shell does is provide a slightly more convenient way to use the underlying system calls - via libraries of very simple C routines. Though an interpretive language, each utility provided by bash is actually very efficient (since small bits of C code). But C doesn't store data as ASCII strings at all (in fact C doesn't 'really' have a concept of 'ASCII string' handling at all), everything is stored as binary with an address pointer marking the beginning and a null character (a binary byte) marking the end of the so-called 'string' (a binary string). i.e. its stored as binary, not ASCII. Pipes handle binary data, not just ASCII and the facility is actually provided by C system calls; bash just provides a human user interface to the facility.DMcCunney wrote: First, Unix was developed by programmers, who wanted a better environment for software development. Software source code is all ASCII, and the implicit assumption of the shell and pipelines is that programs are passing around ASCII strings. If the data you are diddling is not ASCII, this breaks down.
So why look for a C extension module to bolt onto Python in order to get rid of bash (or Bourne, Korn or the C shell etc)? Bash IS an optimised extension module written in C for just the purpose required. But the syntax is ugly, because it is so low-level and close to C itself. bash just mirrors the underlying C system calls and, in a way, therefore, UNIX/Linux mirrors C. In human culture the individual, some say, is constructed from language - we 'are' the language that produces us. The relationship between C, bash, and Linux, follows that same model.
But I absolutely agree that much of the time it would be nice to write in a more human-oriented computer language - for much of ALL programming, including scripting. And why have different syntax for that higher level scripting language in comparison with the compiling language for producing faster executables (where speed of execution is critical)? So I also agree thoroughly with the concept being described by BigPilot at the start of this thread and argued strongly for by Mr. Maxwell. Python syntax for both the main system script language AND the compiling language (e.g. Genie) is a holy grail to look for. But you still need bash (as the lower-level C extension module/library of routines) to provide that level of system call interface to the higher level Python or Python-like code. No need to reinvent the wheel - you still need a pretty low level library of system calls such as provided by bash.
The only problem is that Python itself tends to be too big to contemplate using as a scripting language for a Linux distribution which is purposively being kept unbloated in size. Lua would be a better fit. But then we need a version of say Genie that also provides a Lua-like syntax. And the scripting language Lua needs to provide a GUI toolkit that looks good and is compatible with the most popular applications - i.e. a version of Lua, say, that interfaces to a gtk2 toolkit. John Murga's murgaLua uses FLTK, and that is probably its downfall; otherwise I'm sure such a tiny, powerful language would have been a permanent part of all Puppy distributions.
Useful though gtkdialog has been to the Puppy community, it is limited in power (and that limitation has a major effect on Puppy development in my opinion); Genie/Vala looks like a very positive way forward (but still I'd like a scripting language with the same or similar syntax (with bash as an extension to provide the lower-level pipe interface and so on). Because of the size factor, I still favour a Lua syntax, especially since Lua, like Python is useful as a cross-platform language and a very popular language, actively used by the gaming community for scripting purposes. If only Genie/Vala was more popular/cross-platform, maybe C and C++ would become less important (which would make a lot of people happy since they are hardly considered easy to learn, like alone the associated "popular" GUI toolkit interfaces for them).
Like MU, however, I find Python difficult to learn (I tried hard to master it years ago); my brain alas appears to have become hard-wired to C-like syntax; I absolutely love "pointers" and pointers to pointers and so on - nothing else makes much sense to me any more! It is clearly a sickness. You just need to look at Python code syntax and realise that it 'should be' regarded as much more human friendly, but it is just too abstracted for my engineer trained taste. I can 'see' how the 'actual' data moves about when I read a C program; I have to LEARN data structures in Python that mean absolutely nothing to me in terms of what goes on underneath. But yes I know that UNIX isn't really written in C; at the end of the day its machine code that produces the REAL REAL magic (but only Sage wishes we would all still resort to that - in the form of assembly language code)... :-) Lua isn't 'quite' as pretty or obvious as Python to look at, so I honestly believe that I have a much better chance of mastering it.