Page 2 of 3

Posted: Mon 22 Aug 2011, 19:47
by big_bass
I only use bash
* but if you are using another shell this runs only in bash*
you can take advantage of arrays using bash

(I credited amigo in a prior thread for the code base and pasted the original code a few posts ago )* I will include a diff patch for clarity

I put a safety in there all files get generated in /tmp/desktop
so if you are happy with the results you could manually copy over the
old desktops (thats your call) the user woud have to repackage all the packages with the new desktops to do the job right

I replaced the underscore with the "+" because some files may use underscore in names

Code: Select all

#!/bin/bash

make a template of all the desktops and lets you view them in /tmp/desktops 
so none of your original desktops get overwritten 

builds an array for speeding up any scripts that search info from the desktop

now all your desktops will have a format and an organized  template
the first line is [Desktop Entry],Name,Icon,Categories,Exec,Comment

and thats what you will expect to see when you search the desktops for info  


#[Desktop Entry]
#Name=AbiWord
#Icon=/usr/share/icons/abiword_48.png
#Categories=Application;Office;WordProcessor;GNOME;GTK;X-Red-Hat-Base;
#Exec=abiword
#Comment=Compose, edit, and view documents





# make a template  of the desktops regenerate all desktops  to the new simple template
# removes poorly formatted desktops and creates a standard  which allows later  for easy reading of strings 
# into an array to speed up scripts since the newly generated desktops maintain a standard format
# less commands are needed to filter data for output this is where all the time is wasted 
# having to parse poorly formatted files from the start if you have organized files
# everything is fast and easy to  parse the code

:>arraytest.txt
mkdir -p /tmp/desktops

for DESKTOP_FILE in /usr/share/applications/* ; do
#for DESKTOP_FILE in /usr/share/applications/Editra.desktop ; do
    while read LINE ; do
      case $LINE in
         Name=*) NAME="${LINE[@]}"'|'   ;;
         Icon=*) ICON="${LINE[@]}"'|'   ;;
         #Terminal=*)
         #Type=*)
         Categories=*) CATS="${LINE[@]}"'|'   ;;
         Exec=*) EXEC="${LINE[@]}"'|'   ;;
         Comment=*) COMM="${LINE[@]}"'|'   ;;
      esac      
   done < $DESKTOP_FILE
   echo $NAME$ICON$CATS$EXEC
   # To test the extract function below, use the following line instead of above
   # fixes spaces in the string names by replacing them with a "+" making a correctly formatted array
    echo '[Desktop+Entry]|'$NAME$ICON$CATS$EXEC$COMM | tr ' ' '+'  >>arraytest.txt
    #uncomment if you want to generate all new desktops in /temp/desktops
    echo '[Desktop+Entry]|'$NAME$ICON$CATS$EXEC$COMM | tr ' ' '+' | tr '| ' ' ' | tr ' ' '\n' | tr '+' ' '>/tmp/desktops/`basename $DESKTOP_FILE`
done

Posted: Wed 24 Aug 2011, 04:45
by technosaurus
here is an example I cooked up that includes recursion, string manipulation, and integer math

Code: Select all

#!/bin/ash
A=$(($1/16))
HEX=0123456789ABCDEF
[ $A -gt 15 ] && dec2hex ${A} || printf ${HEX:$A:1}
printf ${HEX:$(($1%16)):1}
A=$(($1/16))
$1 is the input, this stores the "div" of the input by 16 (div is integer only without a remainder so 15 div 16 is 0 but 17 div 16 is 1)

HEX=0123456789ABCDEF
this shows how strings are really just an array of characters

[ $A -gt 15 ] && dec2hex ${A} || printf ${HEX:$A:1}
this is the recursive part, if the "div" is greater than 16, then we haven't gone enough hex place values, so call ourself with the div to shift back one ... note that nothing further happens until the last place value is reached (div is < 16) and the all recursive calls to dec2hex return... this last one only will print its div (in HEX format) the value after the first ":" is the starting point of the substring, and the value after the second ":" is the length of the substring

printf ${HEX:$(($1%16)):1}
similar to above printf statement except that it prints the "mod" (the remainder of input div 16) ... notice that all recursive calls will execute this code

now just to show the value of using functions instead of external scripts

try it like this:

Code: Select all

#!/bin/ash

dec2hex(){
A=$(($1/16))
HEX=0123456789ABCDEF
[ $A -gt 15 ] && dec2hex ${A} || printf ${HEX:$A:1}
printf ${HEX:$(($1%16)):1}
}

dec2hex $1
  • # time dec2hex 999999999999999999
    DE0B6B3A763FFFF
    real 0m0.034s
    user 0m0.032s
    sys 0m0.024s
    # time dec2hex 999999999999999999

    and if you want a generalized format for any base

    Code: Select all

    #!/bin/ash
    
    #note that base64 is traditionally A...Za...z0...9+/ (yeah wtf)
    dec2baseN(){
    A=$(($1/$2))
    STRING=0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+/
    [ $A -ge $2 ] && dec2baseN ${A} $2 || printf ${STRING:$A:1}
    printf ${STRING:$(($1%$2)):1}
    }
    
    dec2baseN $1 $2

Posted: Wed 31 Aug 2011, 00:49
by disciple
Does anyone know: if you source another file, are functions from it run in a new subshell? I don't see why they would be... but I don't know.

Posted: Wed 31 Aug 2011, 01:19
by technosaurus
No, but it does take considerably longer, due to the extra file read.

Things that should be sourced include (not limited to...just examples
Localization (b/c you are only source 1 of X)
Configuration files (can be used/modified by other programs or the user)
A single file that contains all of your needed functions.

Things that usually shouldn't be sourced
Lots of files with a single or a few functions (each read adds time)
A self generated file (you can normally use a variable)

Posted: Wed 31 Aug 2011, 01:43
by disciple
No
Ah, thanks, I confirmed that by testing, too :)

I don't know if anybody here would find it useful, but I see the Arch people maintain "A library providing UI functions for shell scripts"
https://github.com/Dieterbe/libui-sh#readme

Posted: Wed 31 Aug 2011, 08:28
by amigo
When you source a file, it is just as if you 'pasted' the code from it into wherever you sourced in your calling script.

I have one very large shell project -well over 10,000 lines of code. It used all be in one file, but when it got over 3,000 lines I began splitting it up. I do like using functions greatly and name the files after the main function they contain. But, I wouldn't do this for a single small function. In my large project, some of the files containing functions are sourced selectively, according to whether the functions are needed or not.

About the time needed for reading the file in -it takes time each time you check a file attribute using 'test' or '[' and we never shy from that right? And, reading in the contents of the file won't take much longer. And it usually takes much less time than starting some external program -the startup latency from lodaing that into the cache and linking usually takes longer than simply opening a file for read.

Thanks for mentioning 'libui-sh'. I don't think I had seent had one before. There are a couple of others, also, which include a standard set of dialog boxes that will work with several different tools -dialog, Xdialog, zenity, gdialog or even just plain shell. I've found that most of them are too big and overreaching. The ideal setup for creating dialogs would cover a few standard screens like menu-selection, input-box, info-box, yes-no, etc.

I've put lots of time into learning to cerate faster scripts by focusing on replacing often-used standard tools like basename, dirname, cut, cat, etc., with small blocks of bash code.

basename?
${VAR##*/}
dirname?
${VAR%/*}
cat?
while something ; do

done < file-you-wanted-to-cat

Posted: Tue 06 Sep 2011, 12:18
by disciple
Does anyone know if there is a difference between something like `sed -i ... somefile` and `sed ... < somefile`?
I don't think there is, but then why are there both options? Is it because the < isn't available in certain shells or something?

Posted: Tue 06 Sep 2011, 13:16
by big_bass
the sed -i

makes the changes in the "original file" permanent

and the other command without the -i just lets you see what would happen
only the terminal shows the results the original file is unchanged


sed is a great tool but... it looks like taking modem noise and then converting it
into a human readable language

sed <modem_noise # is used to generate the command options

Posted: Tue 06 Sep 2011, 13:57
by disciple
True! I guess I should be in bed. The reason I wasn't seeing any difference is because the line in the script I was working on wasn't actually necessary for the data I was testing it with :roll:
Thanks.

Posted: Sun 04 Dec 2011, 14:52
by thunor
I've got some fast portable shell scripting tips that I'd like to note.

Code: Select all

## With bash you can read the first line from a file speedily like this:

echo `<file`

## This you might think is the ash/dash solution:

cat file

## But I've actually found this to be the fastest for ash, bash and dash:

read -r input < file
echo $input
I'm off out in a minute so I'll add some more later.

Regards,
Thunor

Posted: Sun 04 Dec 2011, 16:23
by jpeps
thunor wrote:I've got some fast portable shell scripting tips that I'd like to note.

Code: Select all

## With bash you can read a file speedily like this:

echo `<file`

## This you might think is the ash/dash solution:

cat file

## But I've actually found this to be the fastest for ash, bash and dash:

read -r input < file
echo $input
That prints only the first line ??

echo `<file` doesn't preserve the line feed. "cat file" is faster (on my computer)

Posted: Sun 04 Dec 2011, 23:15
by thunor
jpeps wrote:That prints only the first line ??

echo `<file` doesn't preserve the line feed. "cat file" is faster (on my computer)
Yeah, I should've mentioned that I was only interested in the first line such as when maintaining global variables as files :)

Getting the directory name from a path:

Code: Select all

## This is what you might be tempted to do:

fullpath="/some/path/to some file.txt"
path="`dirname "$fullpath"`"

## But this is portable although you'll need to check that it returns at least root:

fullpath="/some/path/to some file.txt"
path="${fullpath%/*}"
if [ -z "$path" ]; then path="/"; fi
Regards,
Thunor

Posted: Sun 04 Dec 2011, 23:47
by thunor
Checking the first character of a string:

Code: Select all

## You can get the first character using bash like this:

char="${path:0:1}"

## Otherwise you can use this (is there a better way?):

char="`echo $path | cut -c 1`"

## But if you know what you're looking for e.g. making sure that a string has an initial forward slash then you can do this:

case "$path" in
	/*) true ;;
	*) path="/$path" ;;
esac

## It's also useful if you're reading an rcfile and you want to filter out lines starting with a '#'.
Regards,
Thunor

Posted: Thu 07 Sep 2017, 05:30
by technosaurus
thunor wrote:Checking the first character of a string:

Code: Select all

## You can get the first character using bash like this:

char="${path:0:1}"

## Otherwise you can use this (is there a better way?):

char="`echo $path | cut -c 1`"

## But if you know what you're looking for e.g. making sure that a string has an initial forward slash then you can do this:

case "$path" in
	/*) true ;;
	*) path="/$path" ;;
esac

## It's also useful if you're reading an rcfile and you want to filter out lines starting with a '#'.
Regards,
Thunor
thunor wrote:
jpeps wrote:That prints only the first line ??

echo `<file` doesn't preserve the line feed. "cat file" is faster (on my computer)
Yeah, I should've mentioned that I was only interested in the first line such as when maintaining global variables as files :)

Getting the directory name from a path:

Code: Select all

## This is what you might be tempted to do:

fullpath="/some/path/to some file.txt"
path="`dirname "$fullpath"`"

## But this is portable although you'll need to check that it returns at least root:

fullpath="/some/path/to some file.txt"
path="${fullpath%/*}"
if [ -z "$path" ]; then path="/"; fi
Regards,
Thunor
That is what the read builtin is for ... it reads one line into a variable. You can read multiple lines using a while loop or a specific number of characters using -n ... combine this with a case statement and some substring manipulation and you can replace many (slow) calls to external commands like awk, grep, sed, tr and others

Posted: Thu 07 Sep 2017, 10:56
by MochiMoppel
technosaurus wrote:That is what the read builtin is for
In case your "That" refers to thunor's "It's also useful if you're reading an rcfile and you want to filter out lines starting with a '#'.":
Builtins are not necessarily fast. Read loops are slow. Using an external command can be much faster.

Eliminating lines starting with '#'

Code: Select all

while IFS=  read line; do
  case "$line" in
    [^#]*|"") echo "$line";;
  esac
done <  /etc/rc.d/rc.sysinit  
Time:
real 0m0.226s
user 0m0.147s
sys 0m0.030s

Code: Select all

sed '/^#.*/d'  /etc/rc.d/rc.sysinit
Time:
real 0m0.046s
user 0m0.007s
sys 0m0.020s

Even when reading smaller files sed tends to be faster.

Posted: Thu 07 Sep 2017, 20:20
by wiak
Yes, sed can produce some amazingly efficient fast results. So much code with multiple while read loops and pipes via cut and grep which a single sed command can do (via multiple commands to the single called sed instance). There are also many instances of multiple sed calls being then re-piped into sed again and sometimes again, when a single sed call (with multiple sed command instructions can do).

Part of the problem is that many just know simple basics of sed (mainly just sed 's\\\;'. It can do a lot more than that and all on the one line... but a bit of a learning curve understanding all the things it can do and how to do them altogether in one sed call instance.

wiak

Posted: Thu 07 Sep 2017, 21:30
by sc0ttman
i only know what you guys have shared, but this seems legit:

David Butcher: Speeding Up Your UNIX Shell Scripts
http://www.los-gatos.ca.us/davidbu/faster_sh.html

And i am guilty of piping sed to sed, among a thousand other shell-related sins..

Posted: Fri 08 Sep 2017, 03:54
by wiak
sc0ttman wrote: And i am guilty of piping sed to sed, among a thousand other shell-related sins..
Yes, me too, but doesn't matter anyway as long as not in some long loop type situation - sometimes/often it's more important the code is easy to read. Nice link about shell code speed up by the way.

I'm pretty sure jlst is constantly tuning woof-CE code to gradually speed it up, but there is a lot of code to work though - plenty of speed up possible I'm sure.

wiak

Posted: Fri 08 Sep 2017, 11:52
by sc0ttman
Yeah, that link it quite good.. Some stuff I never even considered..

I like the idea of replacing

Code: Select all

[ "$var" = 'foo' -a "$var2" = 'bar' ] && echo blah
with

Code: Select all

case "$var1$var2" in
  foobar) echo blah ;;
esac
Although readability is not great (imho)..

Posted: Fri 08 Sep 2017, 11:54
by sc0ttman
Is this

Code: Select all

if "$var" = 'foo'; then 

faster or (different at all) than this:

Code: Select all

if [ "$var" = 'foo']; then 
?