Thanks for providing this Ttuuxxx
Puppy is at present largely customised Bash scripts

Combine a bit of bash with gtkdialog3 and you can create simple but immensely useful customized programs
Even I have done it with YAP for example . . .
http://puppylinux.org/wikka/BuddhistYAP_________________Puppy WIKILast edited by Lobster on Mon 05 Dec 2011, 14:35; edited 1 time in total

It's one of the best resources I know for shell scripting, and covers a lot more than just bash.

(Note that bash derives from the AT&T System V Bourne shell, with enhancements made on the Korn shell and some stuff first implemented in the C shell created by Bill Joy for BSD Unix. It tries to be a combination of all of them. Unfortunately, the Bash scripting guide doesn't specify which bits are specific to bash.)
______
Dennis

There is a program -perl script actually, called 'bashisms' which will purify scripts of bashisms. Very handy for creating more portable scripts. It is part of debian devtools, but has its' own project page on sourceforge.

You can also search for a web-page called 'lintsh' which lists some other quirks of many different shells.

I've been doing a lot of work lately on optimizing scripts to use the dash shell instead of bash because it runs 25-40% faster. But I have always been a 'basher', so my normal way of coding includes lots of 'bashisms'. The bashisms program and the notes on lintsh make it easier to find the parts that need to be changed to use dash, ash or other mostly POSIX-compliant shell. There are a couple of other things to watch for to be able to run scripts using a Bourne-compatible shell. There is a modernized version of the Bourne shell available from the 'heirloom' tools site on source forge -search for 'heirloom-sh'. It runs compliant scripts another 10-15% faster than dash.
Recently I wanted alter a script to not use an awk construct:
| awk ' { print $1 } '
My first attempt using shell code ran three times slower than calling awk. I went at it again and came up with a routine that runs 10 times faster than calling awk! I usually try to 'factor out' all calls to sed or awk, unless it is clear that using the external tools is faster.

There is a program -perl script actually, called 'bashisms' which will purify scripts of bashisms. Very handy for creating more portable scripts. It is part of debian devtools, but has its' own project page on sourceforge.

The page is here: http://sourceforge.net/projects/checkbaskisms/

Quote:

I've been doing a lot of work lately on optimizing scripts to use the dash shell instead of bash because it runs 25-40% faster.

Other distros use "ash" for the same purpose. As far as I can tell, ash is bash without all the code meant for interactive use at a command line. It's just an interpreter for the shell language, and preferable for things like install scripts.

Quote:

There is a modernized version of the Bourne shell available from the 'heirloom' tools site on source forge -search for 'heirloom-sh'. It runs compliant scripts another 10-15% faster than dash.

It's part of http://heirloom.sourceforge.net

The trick is "compliant" scripts. The Bourne shell is not POSIX compliant (as the POSIX specs evolved well after the Bourne shell was written.) Hopefully, the heirloom shell is based on SysVR2 or later code, when shell functions got added to the Bourne shell.

Quote:

Recently I wanted alter a script to not use an awk construct:
| awk ' { print $1 } '
My first attempt using shell code ran three times slower than calling awk. I went at it again and came up with a routine that runs 10 times faster than calling awk! I usually try to 'factor out' all calls to sed or awk, unless it is clear that using the external tools is faster.

What did your revised routine look like?

The original Bourne shell language was minimal, intended to be used as glue to tie together external processes like awk or sed, and was mostly flow-of-control constructs. I'm an old Korn shell user, and one of the enhancements the Korn shell made was making things like "echo" a built-in rather than calling an external program, and adding built-in integer arithmetic so you didn't have to call eval. There's a sample Korn shell script that implements grep in the Korn shell. It's mostly a proof-of-concept - calling the real grep will almost certainly be much faster for any non-trivial search - but it was a neat example of what could be done entirely in the shell.

Versions of ksh after ksh88 could be successfully installed as /bin/sh on Sun systems (and I did so).

Ubuntu includes ksh, and I looked at trying to move it to Puppy, but there are library dependencies I didn't have time to track down when I looked.

There is also the Z shell - zsh - with a PET available for Puppy.

See http://en.wikipedia.org/wiki/Z_shell and the Sourceforge page at http://zsh.sourceforge.net/

(I have a Win32 port of zsh as part of the UNXUTILS package.)
______
Dennis

Thanks for supplying those links. Sometimes I use the Alfred Stieglitz approach and only give a few clues and let the reader do the searching -when things aren't hard to find.
Alfred Stieglitz was a famous turn-of-the-century(20th) photgrapher who was married to Geogia O'Keefe. He was the first person to exhibit Matisse's work in the USA, at his studio in New York. He had no business cards for the studio, and when asked about it he said: "If a man wants something, he'll find it".

Anyway,
heirloom-sh is SVR4 compliant and includes functions and other 'goodies'. if invoked as 'jsh', it includes job-control, so it could be used as a login shell -but I don't even set it up as /bin/sh. There are too many scripts out there which use /bin/sh, but only if /bin/sh is a link to bash.

About dash/ash. ash is mostly POSIX-compliant, but dash claims to be fully POSIX-compliant. You'll find that the busybox version of ash is not the same as the real ash -you need to write Bourne-compliant code for busybox ash (especially regarding the use of `code` backticks instead of $(code) constructs. Another difference between POSIX and Bourne is that Bourne lacks the 'test -e file' (or [ -e file ])check.

So, for installers and initrd's which use busybox, it is best to use only Bourne-compliant syntax.

I seem to have deleted my original version which was slower than the real thing, or I'd post that, too.
The original script I was modifying used awk like that in 2 or 3 places and also sed. By rewriting those sections and getting rid of useless sort |uniq statements and making everything Bourne-compliant, I was able to make the script run about 40% faster using dash and around 50% faster using heirloom-sh.
Here's the sed trick:
Original code:

Code:

BINDIRS="$(echo ${PATH} | sed 's/:/ /g;s/\.$//')"

New code:

Code:

BINDIRS="`IFS=: ; echo ${PATH}`"

Here'S another nice trick for speeding up a common routine -to check if a file is an ELF binary. Original:

Using dd to check for the file signature is safer than running file, and is much faster than calling a file|grep construction -really noticeable where the rouitn gets called 100's/1,000's of times haven't checked specifically, but probably also at least 50% faster...

Thanks for supplying those links. Sometimes I use the Alfred Stieglitz approach and only give a few clues and let the reader do the searching -when things aren't hard to find.
Alfred Stieglitz was a famous turn-of-the-century(20th) photgrapher who was married to Geogia O'Keefe. He was the first person to exhibit Matisse's work in the USA, at his studio in New York. He had no business cards for the studio, and when asked about it he said: "If a man wants something, he'll find it".

I know who Stieglitz was. I also live in walking distance of the site of the famous "Armory Show" in 1913

Quote:

Using dd to check for the file signature is safer than running file, and is much faster than calling a file|grep construction -really noticeable where the rouitn gets called 100's/1,000's of times haven't checked specifically, but probably also at least 50% faster...

dd is bigger than file, but using file requires calling grep, too, so I see where the speedup comes from.

Have you experimented with setting the sticky bit on something like dd before doing this?

Have you experimented with setting the sticky bit on something like dd before doing this?

I don't understand what you mean -I know about the sticky bit, but don't understand how it relates here...

I'm thinking about repeatedly calling a utility in a script.

In the old days, I set the sticky bit on various things I'd have occasion to call repeatedly in a script, like echo. Setting the sticky bit forced the executable to be kept in swap, where it could be reloaded more quickly, and helped execution times on scripts that called things repeatedly. (Back then, /bin/sh was the Bourne shell, and echo was an external command, not a shell built-in. Having echo as a built in in the Korn shell was one reason I clutched it happily to my chest.)

I haven't really played with doing it in Puppy, and don't know how it might affect things. (And thinking about it, I might copy stuff used like that in the script to /dev/shm and run it from there.)

Quote:

Using dd may also be safer than file -I have heard of security risks using file, but haven't seen full info.

I'd be curious to know more. File is looking at the file header and using a "magic number" to decide what type of file it is. I fail to see how simply opening a local file and reading the header constitutes a security risk.

Quote:

I also wrote and use a clone of ldd which uses objdump and is lots safer than ldd itself which actually executes a binary to check its' deps.

Is there some concern that the binary it executes might not be the one you expect, and may have malicious effects?
______
Dennis

Maybe you can dish out some pocket money and find "The Linux Shell Handbook", a special issue Linux Pro magazine, published in Spring 2010.
Might still be on the shelves of magazine outlets as of this writing.

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