Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 13 Dec 2018, 04:58
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
I've seen the future of Linux...
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 4 [56 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Author Message
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15239
Location: Paradox Realm

PostPosted: Wed 18 Mar 2009, 07:15    Post subject:  

Quote:
I guess I'm going to have to learn genie.


Yes Very Happy
http://puppylinux.com/genie/

You could even create a python to genie parser
- improving your understanding of both languages Smile

Even I am having a go . . .
http://www.murga-linux.com/puppy/viewtopic.php?p=283314#283314

Barry and MU have a record of producing Puppy code

Vala is being used by Gnome
Linus has recently moved to using Gnome
So the future is set already

Can you do a parser? Cool

_________________
YinYana AI Buddhism
Back to top
View user's profile Send private message Visit poster's website 
DMcCunney

Joined: 02 Feb 2009
Posts: 894

PostPosted: Wed 18 Mar 2009, 07:58    Post subject:  

Pizzasgood wrote:
One way of processing files with Bash is with the read command, by piping the contents through 'while' with 'read LINE' as the test:
Code:
cat /some/file.txt | while read LINE; do
   echo "The following line is one line of text from /some/file.txt:"
   echo $LINE
done

I wasn't aware of the 'let' command. I've been using eval for things that need to be ash-compatible, and $[$VAR+$i] for Bash-only things. The square brackets are much faster than eval in Bash and slightly faster than let, but are not supported in ash. The 'let' is many many times faster than 'expr', and ash using let is significantly faster than Bash with any of the above. And the speeds of let and square-brackets are even closer when using #!/bin/sh rather than #!/bin/bash. So I'm going to be using let from now on. Good stuff. Thanks.

Let was first added in the Korn shell, and Bash got it from there. Performance improvements were a focus of ksh, and one solution was built-ins to replace things like eval that had to be called as external commands. Replacing /bin/echo with a built-in (that is an alias to the print primitive) was another example.

Ash is effectively the Bourne shell script language without various of the improvements of ksh and bash. Most of the scripts that control *nix systems are in the Bourne dialect, and ash is smaller and faster to load, so it often gets the nod for non-interactive usage.

<...>

Quote:
They all have a loop or two. But the actual tasks are mostly using generic programs like 'cp', 'tar', 'mencoder', etc. What benefit would there be in using Python for that? It seems to me like doing that stuff in anything else would just be inserting an extra layer of complexity.

I'm not trying to be argumentative. I've actually been very tempted to use things besides Bash on some projects, particularly things that need arrays. But for the above examples, it seems to me like Bash is ideal for them.

Python is an interpreted language powerful enough that you can write complete applications in it, including fancy GUI stuff using PythonTK. It's also cross-platform, and available for Windows, Mac OS/X, and *nix. (I have several text editors in my collection written entirely in Python, and a couple of others that use Python as an extension language. Eric S. Raymond was going on at one point about what Lisp got wrong and Python got right. I suggested he rewrite Gnu Emacs, which is based on Lisp, to use Python instead, and he said "Don't tempt me!" Razz )

Modern hardware is fast and powerful enough that it's feasible to use an interpreted language instead of a compiled one, and the interpreted nature can speed development and debugging. (Python does compile to "bytecode", ala Java, but that's not the same thing as compiling to native machine code.) It's aimed at a different problem domain than shell scripts.

Most current Unix and Linux distros I'm aware come with Python, (and Perl and TclTk)as basic parts of the distribution. Puppy is unusual in not including it by default.

You *can* use Python to diddle the ASCII data comprising most *nix config files, and I recall seeing at least one Linux distro that does

Quote:
Now, in a script I recently wrote that does some weird interactions with the output of some 'git' commands, maybe Python would have been easier than all the calls to 'grep' and 'sed' and futile attempts to get Bash's string and array parsing to work the way I needed.

The usual solution to that is to use Perl, which is intended for just such cases, and replaces sed and awk.

The shell (whether ash, bash, csh, tcsh, zsh or whatever, is intended to be a glue language, where you couple together other programs in a pipeline to do what you want to do, with the shell providing high-level control constructs. The drawback is two fold:

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.

Second, pipelines are one dimensional, and assume a linear set of processing steps. Not all processing lends itself to that approach. (There was an experimental effort called the 2D shell that supported more complex processing models, but I don't believe that ever made it out of Bell Labs. (I've only seen it referred to in papers and documentation.)
______
Dennis
Back to top
View user's profile Send private message 
DMcCunney

Joined: 02 Feb 2009
Posts: 894

PostPosted: Wed 18 Mar 2009, 08:10    Post subject:  

Lobster wrote:
Quote:
I guess I'm going to have to learn genie.


Yes Very Happy
http://puppylinux.com/genie/

You could even create a python to genie parser
- improving your understanding of both languages Smile

Even I am having a go . . .
http://www.murga-linux.com/puppy/viewtopic.php?p=283314#283314

Barry and MU have a record of producing Puppy code

Vala is being used by Gnome
Linus has recently moved to using Gnome
So the future is set already

Can you do a parser? Cool

Genie bears some syntactic resemblance to Python, so I suppose you might be able to do it, but I'm not sure why you should. The advantage you would get is that Genie "compiles" to C, which is then compiled to native machine code, so your executable will theoretically be faster. But if that's a concern, you are better not writing in Python in the first place, or translating Python code to C without the intermediate Genie step.)

Modern hardware is fast enough that you can often write in Python and not have to resort to C. Performance will be quite acceptable.

This breaks down somewhat in Puppy, which tends to be used on older hardware that may not be fast enough.

Incidentally, poking around a bit, it appears Geany has a Vala mode.
______
Dennis
Back to top
View user's profile Send private message 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15239
Location: Paradox Realm

PostPosted: Wed 18 Mar 2009, 08:48    Post subject:  

Yep if speed is no problem the future would be the slowly
but easy to use Ruby.

My approach is what language is being used by Puppy developers
or being explored by them?

What they write
is our future.

One day we may end up using ASQ which requires some developments
in hardware, AI and programming mentality . . .
http://tmxxine.com/Wikka/wikka.php?wakka=ASQinDevelopment

_________________
YinYana AI Buddhism
Back to top
View user's profile Send private message Visit poster's website 
DMcCunney

Joined: 02 Feb 2009
Posts: 894

PostPosted: Wed 18 Mar 2009, 10:22    Post subject:  

Lobster wrote:
Yep if speed is no problem the future would be the slowly
but easy to use Ruby.

If you can deal with Ruby, you can deal with Python. Ruby was developed to address perceived lacks in Python.

The main use of Ruby I'm aware of therese days in in "Ruby on Rails" web development.

Quote:
My approach is what language is being used by Puppy developers
or being explored by them?

What they write is our future.

You will be better served to consider just what problem you are trying to solve. There is a reason why so many languages exist, and there isn't a "one size fits all" solution.

The first question I'd ask is "What do you plan to develop in Genie?" Depending on the answer, it's possible you'd be better off using something else.
______
Dennis
Back to top
View user's profile Send private message 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Wed 18 Mar 2009, 17:56    Post subject:  

Genie is nice but because it is compiled we don't want to use it for everything. Python has the advantage of being much more powerfull and faster than bash, as I have stated many times earlier if a C extension module was devolpoed for shell like commands and made part of the Python version of puppy BASH would have no advantage at all. I have no problem with working hard at devoloping the above stated extension module, I just have a few questions...

1. Who is willing to help me?
2. What features does this Python shell need?
3. What is the prevailing GUI system for puppy?
4. How can I contact the guy who made Genie?

The way I see it the future of Puppy (or Linux in general) is Genie/Python.

_________________
Super amazing game!
Back to top
View user's profile Send private message 
Pizzasgood


Joined: 04 May 2005
Posts: 6266
Location: Knoxville, TN, USA

PostPosted: Wed 18 Mar 2009, 22:10    Post subject:  

Quote:
1. Who is willing to help me?

Not me. I have too many other projects either planned or underway as it is. Laughing

Quote:
2. What features does this Python shell need?

If you want to replace Bash, it needs to be able to handle the situations I showed at least as elegantly as Bash did. And if you want to completely replace Bash, to the point where it isn't even included, you'll have to either write a bash (or at least sh) emulator, or have a wrapper named "bash" set up to run the script through a bash->python translator and then run the translated script with Python. Gotta support that occasional bash script you'll get from random 3rd party packages.

Quote:
3. What is the prevailing GUI system for puppy?

GTK 2

_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send private message 
Mr. Maxwell


Joined: 30 Aug 2008
Posts: 215
Location: Nebraska, USA

PostPosted: Wed 18 Mar 2009, 22:31    Post subject:  

Pizzasgood wrote:
If you want to replace Bash, it needs to be able to handle the situations I showed at least as elegantly as Bash did. And if you want to completely replace Bash, to the point where it isn't even included, you'll have to either write a bash (or at least sh) emulator, or have a wrapper named "bash" set up to run the script through a bash->python translator and then run the translated script with Python. Gotta support that occasional bash script you'll get from random 3rd party packages.


I don't even want to think about any kind of BASH translator Sad . (the syntax sucks) Getting Python to the stage were BASH is not needed is a long way off anyway so there's some time still. Smile But, would someone make a list of features a good shell needs? I really have no idea so if someone could either link a list or write one up that would be wonderfull.

Thanks.

_________________
Super amazing game!
Back to top
View user's profile Send private message 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15239
Location: Paradox Realm

PostPosted: Wed 18 Mar 2009, 23:11    Post subject:  

Mr. Maxwell wrote:

4. How can I contact the guy who made Genie?


Jamie Mccracken
    Blog/Web page: http://jamiemcc.livejournal.com/
    Email: jamiemcc@gnome.org

_________________
YinYana AI Buddhism
Back to top
View user's profile Send private message Visit poster's website 
Pizzasgood


Joined: 04 May 2005
Posts: 6266
Location: Knoxville, TN, USA

PostPosted: Thu 19 Mar 2009, 01:22    Post subject:  

Quote:
But, would someone make a list of features a good shell needs? I really have no idea so if someone could either link a list or write one up that would be wonderfull.
Maybe you should get some experience with shell scripting first. I mean, if you want to replace something, you kinda need to know what you're replacing in great enough detail to do a good job. Know thine enemy, they say.

Pipes are essential. Basic math. Loops. Switch/case. If/else. String parsing. Arrays. Launching other programs easily. Redirecting the stdout and stderr of said programs easily. Ability to fork, background, foreground, and kill processes. Interacting with files easily. Interacting with the user easily.

_________________
Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Thu 19 Mar 2009, 07:25    Post subject: bash AS the C extension module for Python and so on  

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.


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:

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.


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.

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.

Last edited by mcewanw on Thu 19 Mar 2009, 07:50; edited 3 times in total
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Thu 19 Mar 2009, 07:43    Post subject: C can do more than bash since it's a lower level language  

On further reflection, and to be fair to DMcCunney, it is true that though the pipe mechanism provided by C system calls themselves handle binary data and not just ASCII the slightly higher level interface provided by bash, for example, basically expects ASCII strings (which can be a real nuisance/drawback at times). The answer to that is generally to rewrite the whole bash script in C with calls to the std libs (which is often a relatively easy thing to do) or to simply interface the main bash script with a small C utility, which accomplishes the lower level trickery that the more general purpose bash cannot.
Back to top
View user's profile Send private message Visit poster's website 
DMcCunney

Joined: 02 Feb 2009
Posts: 894

PostPosted: Thu 19 Mar 2009, 09:21    Post subject:  

Mr. Maxwell wrote:
I don't even want to think about any kind of BASH translator Sad . (the syntax sucks)

Compared to what? The base syntax is System V Bourne shell, with some ksh and csh stuff tossed in. It's not that crufty.

Quote:
Getting Python to the stage were BASH is not needed is a long way off anyway so there's some time still. Smile But, would someone make a list of features a good shell needs? I really have no idea so if someone could either link a list or write one up that would be wonderfull.

Don't even try.

Remember that the shell is two things: a script language intended as glue to tie together other processes to perform a task, and a command interpreter the user will deal with in a terminal.

I don't see an advantage to trying to replace bash, and a large number of potential pitfalls, since most of the control structures for *nix are shell scripts.

Bash isn't intended to write applications. It's handy for system admin tasks and for prototyping, but if performance is a consideration, you write
in something like Python or C.
______
Dennis
Back to top
View user's profile Send private message 
DMcCunney

Joined: 02 Feb 2009
Posts: 894

PostPosted: Thu 19 Mar 2009, 09:44    Post subject: Re: C can do more than bash since it's a lower level language  

mcewanw wrote:
On further reflection, and to be fair to DMcCunney, it is true that though the pipe mechanism provided by C system calls themselves handle binary data and not just ASCII the slightly higher level interface provided by bash, for example, basically expects ASCII strings (which can be a real nuisance/drawback at times).

It's not just bash (or the Bourne shell, C shell, Korn shell, Z shell, etc.). The various utilities you call from shell scripts also tend to assume ASCII strings. Awk, diff, grep, sed, tr and the like are intended to process ASCII files. As mentioned, the developers of Unix were software developers, and many of the utilities provided with a *nix system are intended to manipulate and transform source code in various ways.

Quote:
The answer to that is generally to rewrite the whole bash script in C with calls to the std libs (which is often a relatively easy thing to do) or to simply interface the main bash script with a small C utility, which accomplishes the lower level trickery that the more general purpose bash cannot.

Precisely. If what you are dealing with is binary data, a shell script may be the wrong approach to take.

Each language has a problem domain it addresses, and you use the language appropriate for the problem.

"If what you have is bash, you see everything as a shell script" is the source of a lot of confusion.
______
Dennis
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 3200

PostPosted: Thu 19 Mar 2009, 10:04    Post subject: could scrap bash though, or use it much less...  

Bash is used as the glue described by Mr McCunney. In theory bash could be "done away" with though. I just agree with Pizzagood, however, that for legacy reasons, and also because bash is quite an efficient shell interface anyway, that it is best to keep bash, even in a Linux distribution that plans to use something like Python for ALL the system scripts (e.g. with the init process calling up Python startup scripts from inittab).

In many ways I do nevertheless rather like the concept of replacing the usual set of bash startup scripts with some higher level scripting language scripts (which may also use bash as an underlying extension in handling stdio, pipes and so on, even if that sounds a bit back to front...). Should be easier to maintain and simpler to read (since higher level language). Even some Puppy linux startup bash rc scripts are complicated enough that they would benefit from being re-written in a higher level scripting language, methinks - which conceptually is where this thread started off.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 3 of 4 [56 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1151s ][ Queries: 12 (0.0210s) ][ GZIP on ]