On Thu, Oct 26, 2000, Chen Shapira wrote about "[hackers-il] Mouse vs.
keyboard":
>...
> Each and every user was able to perform the task using the mouse
> significantly faster, an average of 50% faster.
>...

I'm sorry, but I completely don't buy this research (but note that I haven't
read it - I'm just speaking "theoretically").

Are you sure this wasn't one of those "Scientific Maariv" articles? :)


The efficiency of using the keyboard vs. the mouse depends on the features
the OS offers the user, so it doesn't make sense to talk about this issue
without comparing actual operating systems.

For example, to copy a file on a Windows machine, it is obvious that
drag-and-drop is quicker than opening a DOS window and using the "CD", "DIR",
and "COPY" commands. However, how do you, using the "faster" Windows Explorer,
copy all the GIF files under some directory (and its subdirectories) to
another drive? You'll probably be forced to do it one by one, and believe me,
while using the mouse is very efficient for doing one thing, it because
horribly inefficent when repeating an action several dozen times. On the
other hand, in Unix, using zsh (for example), I just do
	  cp /some/directory/**/*.gif /another/directory
which is much faster than the mouse way.

Another example, suppose you compare the ease of printing a Word document
(click the load icon, choose file with mouse, click print button) to
the difficulty of printing a tex file (suppose for a moment that you don't
have a GUI for tex) - typing "latex" and "dvips" commands. Is this really
a good comparison? No. Why? First, people tend to repeat commands (you print
the file, pick up the printout, find an error, correct it - and then you
print it again), and modern shells make it very easy to repeat commands.
Second, what happens when you need to print, say, 10 documents? It takes
me less than 30 seconds to type
	 for i in *.tex
	 do
		 j=`basename $i .tex`
		 latex $j
		 dvips $j
	 done
and it will take me much more than that to load and print 10 files into
Word (forgetting that you can probably do that in VB - VB is more commonly
used by virus writers than actual users).

People may argue against what I said by saying that typical users don't
need such sophisticated loops and repetitions of commands. I say they're
wrong - beginner, unsophisticated, users may not need them, and find Windows
very convenient. But once you learn a little more about your computer, Windows
starts being a strait-jacket. Some users learn to accept that strait-jacket,
thinking it is natural, but others (like me) refuse to accept it.

I once spent half a day trying to insert about a 100 pictures (each about 1 MB
in size) to a report I was writing in MS-Word. It was hell. I had to manually
resize, load, manipulate, etc., each and every picture, most of which were
nearly identical. After several hours, I gave up. Instead, I printed an empty
page (except the headers) to Postscript, and then wrote a shell script (took
me about 30 minutes) which ran various commands on each image, transformed it
to Postscript, and overlayed 3 pictures on each blank page (after changing the
page number). The result looked very good, and it also allowed me to switch
the entire set of 100 images at a later time, without any more work. Now that
is what I call efficiency. It wasn't easy, but it was quick (30 minutes
vs. hours of work), even quicker to do again if you find an error (just run
the shell script again), and not boring (for some reason the article you
quoted thinks that "engaging the mind" is a bad thing. I disagree, and find
repetitive, boring, tasks much worse).

In short my theory is that keyboard (command line) UI lends itself much
better to repetition and autmation, which makes it more efficient in the
long-run than mouse (graphical) UI for experienced users. Of course, having
both kinds of interfaces implemented well (see, for example, Emacs) is the
best thing, because it wins in both contests: it allows for easy one-time
tasks, and easy automation.


--
Nadav Har'El                        |      Friday, Oct 27 2000, 28 Tishri 5761
nyh@...             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |War doesn't determine who's right but
http://nadav.harel.org.il           |who's left.

On Thu, Oct 26, 2000 at 06:15:09PM +0200, Chen Shapira wrote:
> To all hard-core hackers claiming that using the keyboard is much faster
> than using the mouse - here's what a study (conducted by apple, one must
> say) reports:
>
> In one study of this phenomenon (Tognazzini, Tog on Interface, 1992.), users
> were asked to do the same task using the keyboard and the mouse. The
> keyboard was powerfully engaging, in the manner of many videogames,
> requiring the user to make many small decisions. The mouse version of the
> task was far less engaging, requiring no decisions and only low-level
> cognitive engagement.
>
> Each and every user was able to perform the task using the mouse
> significantly faster, an average of 50% faster.
>
> Interestingly, each and every user reported that they did the task much
> faster using the keyboard, exactly contrary to the objective evidence of the
> stopwatch.

Interesting. Do you have a URL for that?


	 - Adi Stav

> Are you sure this wasn't one of those "Scientific Maariv" articles? :)
>

The reference I gave was to one of the more respected books in the HCI
field.
But as I said, the research was conducted for Apple.

> The efficiency of using the keyboard vs. the mouse depends on
> the features
> the OS offers the user, so it doesn't make sense to talk
> about this issue
> without comparing actual operating systems.

Not true. One can give a similar task that can be done in a similar way with
both a mouse and a keyboard, one can test the speed of working with the
device, as opposed to the power of the OS.

There are wide diffrenced between mouse based OS's.
Grabbing a toolbar is much faster in Mac than under windows, the multi-level
menus are also faster under the mac.
I'm talking about a task, not about an OS.

> For example, to copy a file on a Windows machine, it is obvious that
> drag-and-drop is quicker than opening a DOS window and using
> the "CD", "DIR",
> and "COPY" commands. However, how do you, using the "faster"
> Windows Explorer,
> copy all the GIF files under some directory (and its
> subdirectories) to
> another drive? You'll probably be forced to do it one by one,
> and believe me,
> while using the mouse is very efficient for doing one thing,
> it because
> horribly inefficent when repeating an action several dozen
> times. On the
> other hand, in Unix, using zsh (for example), I just do
> 	 cp /some/directory/**/*.gif /another/directory
> which is much faster than the mouse way.

Why no, I'd use the Find tool, do find for *.gif in the directory, get all
the files I need (find is recursive), and the just select-all and copy to
where ever I need.

It's about knowing the tools, not many people think of the ** trick (I used
to write shell scripts to do what you just described)

About the printing example - again each OS is good in specific things,
batch prints is easier under Unix (although its unfair, more unix users know
shell programming than windows users know VB), but printing a specific
segment from a documents is easier under windows.

In anycase, those are OS attributes, nothing to do with the subject of the
test.

> People may argue against what I said by saying that typical
> users don't
> need such sophisticated loops and repetitions of commands. I
> say they're
> wrong - beginner, unsophisticated, users may not need them,
> and find Windows
> very convenient. But once you learn a little more about your
> computer, Windows
> starts being a strait-jacket. Some users learn to accept that
> strait-jacket,
> thinking it is natural, but others (like me) refuse to accept it.

The fact that some people never learn to use windows doesn't make it a
strait-jacket. Once you learn the OS - its as good and usefull as a Unix.
I'm talking about NT 4.0 here, because thats the only windows version I've
used.


> quoted thinks that "engaging the mind" is a bad thing. I
> disagree, and find
> repetitive, boring, tasks much worse).

I never said that one shouldn't ever ever program, instead he better
repeatedly use the mouse in stupid ways.
I only quoted an article saying that:
	 1. A task that can be performed with and without a mouse in similar
ways can be done with a mouse.
	 2. You may never know it.

If postscript does the job faster than Word - go ahead. Some people may do
it in VB, but again, it isn't related to the mouse VS. keyboard argument.

Engaging the mind isn't bad, it's just misleading, it makes time fly.
Remember the time when you were programming, and were very  suprized to see
its morning already? thats what i mean.


> In short my theory is that keyboard (command line) UI lends
> itself much
> better to repetition and autmation, which makes it more
> efficient in the
> long-run than mouse (graphical) UI for experienced users. Of
> course, having
> both kinds of interfaces implemented well (see, for example,
> Emacs) is the
> best thing, because it wins in both contests: it allows for
> easy one-time
> tasks, and easy automation.

The other example is NT with Cygnus :-)

I'm considering giving a lecture about Bash to the Haifa Linux Club. I
started to write a summary of it and you can find it at the following URL:

http://vipe.technion.ac.il/~shlomif/lecture/Bash/

If you wish, read it and send your comments, either personally to me or to
the list.

Regards,

	 Shlomi Fish


----------------------------------------------------------------------
Shlomi Fish        shlomif@...
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       shlomif@...

The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.

Shlomi Fish wrote:

> I'm considering giving a lecture about Bash to the Haifa Linux Club. I
> started to write a summary of it and you can find it at the following URL:
>
> http://vipe.technion.ac.il/~shlomif/lecture/Bash/
>
> If you wish, read it and send your comments, either personally to me or to
> the list.

Why not do it collectively?


Original summary:

> Summary of sh/Bash Lecture:
> ------------------------
>
> - Executing simple commands: command name followed by parameters
>    Examples:
>        ls
>        ls -l
>        cp test.pl old_test.pl
>
> - Filename Matching mechanisms:
>    *
>    []
>    ?
>    Examples:
>        ls -l *.c
>        cp *.c ./bak_dir


simple readline quickies:

arrows - history
^-r  find command in history by name

readline is NOT shell

>
> - Pipeline: explain a little about standard input/standard output,
> then show
>    the following redirection mechanisms:
>    |
>    >
>    <
>    Examples:
>        ls -l | less
>        cat *.c *h | wc -l
>        ls -l | grep ^d | wc -l

What about :

     ls ./no_such_file 2>/dev/null
     FDT
     ls -l /proc/$$/fd/   to show file descriptors

>
> - The ";" - executing more than one statements in the same batch. A
>    synchronous executions.
>    Examples:
>        cd ./test_dir ; tar -czvf ../test_dir.tar.gz *
>

&&  - conditional execution


The following section is better be given after variables (IMHO)

>
> - The "(" .. ")" - grouping statements inside a _subshell_ (separate
> process).
>    Examples:
>        (cd ./bin ; ls d* ) > files_in_bin_that_start_with_a_d.txt

{}  - same process

put {} and give it a name - function.

Differences:  exported variables vs non-exported variables.

A=1
B=2
export A
{
   echo A is ${A:-"unset"}
   echo B is ${B:-"unset"}
}
(
   echo A is ${A:-"unset"}
   echo B is ${B:-"unset"}
)

Control structures:

do ; done - a block

if ; then ; fi
while
for atom in lat


>
> - Using the backslash (with no whitespace afterwards) to split
> commands across
>   several lines. Eases readability:
>    Examples:
>        cp *.c *.h README Makefile TODO \
>            USAGE INSTALL \
>                ./bak
>
> - Introducing comments with "#". They start with a # and extend to the
> end of
>   the line.
>
> Variables:
> ----------
>
> - Simple assignment: "=". (note that there cannot be any whitespace before
> and after the "=" symbol.)
>    Examples:
>    A=hello
>    B=yellow ; turn=500
>
> - Retrieving the value of a variable using $ or ${} . (not $() !)
>    Examples:
>        - A=hello
>          echo $A
>        - VARIABLE=5
>          B=${VARIABLE}
>          VARIABLE=800
>          echo $B
>        - A=Y
>          Y=80
>          echo ${$A}
>
> - A little about extrapolation: A dollar can appear anywhere. If the shell
>   encounters a $ which is not followed by curly brackets ("{" .. "}")
> it will
>   try to extroplate its name from as many characters as it find, even if
>   a variable by that name does not exist. Thus, when in doubt, use the
>   "${NAME}" form.
>
>    Examples:
>        - A=hello
>          echo $Aworld
>          # does not print helloworld
>
>
> - The "${parameter:-defaultvalue}" form enables you to give the
> expression a
>   default value in case the variable is not assigned.
>    Examples:
>        -
>            #!/bin/bash
>
>            ;
>            ; Possibly set A
>            B=${A:-not_set}
>            ; Check if B is equal to not_set and accordingly do something.
>
> - To unset a variable use the "unset" command:
>    Examples:
>        -
>            #!/bin/bash
>            A=5
>            B=80
>            RESULT=400
>            echo $A \* $B = $RESULT
>            unset A B RESULT
>
> - To display a list of the declared variables and their values, use
> the "set"
>   command without any options. (set is of little use in scripts except for
>   debugging purposes).
>
>   Examples:
>     -
>        A=32482 ; B=932840 ; C=1932840 ; D=890 ; E=hello ; F=world
>        unset A E
>        set | grep '^[A-F]='
>
> - The "read VARNAME" command reads a line from the standard output and
> puts
>   it inside the variable "VARNAME".
>    - Note: Do not use "read $VARNAME"!

Actualy, read $VARNAME is legal...

>
>
>   Examples:
>

`` and $() program substitution.
Why it is better to use $()
Example:
$( cd  $( echo "/usr" ) && pwd )  instead of
`cd \`echo "/usr"\' && pwd`

> Regards,
>
>  Shlomi Fish
>
>
> ----------------------------------------------------------------------
> Shlomi Fish        shlomif@...
> Home Page:         http://t2.technion.ac.il/~shlomif/
> Home E-mail:       shlomif@...
>
> The prefix "God Said" has the extraordinary logical property of
> converting any statement that follows it into a true one.
>
>
>
>
> To unsubscribe from this group, send an email to:
> hackers-il-unsubscribe@egroups.com
>
>

> simple readline quickies:
>
> arrows - history
> ^-r  find command in history by name
>
> readline is NOT shell

And the ! command to use the history

On Tue, 31 Oct 2000, Omer Mussaev wrote:

> Shlomi Fish wrote:
>
> > I'm considering giving a lecture about Bash to the Haifa Linux Club. I
> > started to write a summary of it and you can find it at the following URL:
> >
> > http://vipe.technion.ac.il/~shlomif/lecture/Bash/
> >
> > If you wish, read it and send your comments, either personally to me or to
> > the list.
>
> Why not do it collectively?
>
>
> Original summary:
>
> > Summary of sh/Bash Lecture:
> > ------------------------
> >
> > - Executing simple commands: command name followed by parameters
> >    Examples:
> >        ls
> >        ls -l
> >        cp test.pl old_test.pl
> >
> > - Filename Matching mechanisms:
> >    *
> >    []
> >    ?
> >    Examples:
> >        ls -l *.c
> >        cp *.c ./bak_dir
>
>
> simple readline quickies:
>
> arrows - history
> ^-r  find command in history by name
>
> readline is NOT shell
>

I'm not planning to cover readline too much in the lecture, because:
1. It has lots of options, most of which I never use.
2. Most users are familiar with its basic options (tab, up and down
arrows, etc.)
3. I want my lecture to be as sh (ash) complaint as possible and the use
of readline is unique to bash and zsh.

> >
> > - Pipeline: explain a little about standard input/standard output,
> > then show
> >    the following redirection mechanisms:
> >    |
> >    >
> >    <
> >    Examples:
> >        ls -l | less
> >        cat *.c *h | wc -l
> >        ls -l | grep ^d | wc -l
>
> What about :
>
>     ls ./no_such_file 2>/dev/null
>     FDT
>     ls -l /proc/$$/fd/   to show file descriptors
>

I plan to cover 2> 2>&1, etc. later on.

> >
> > - The ";" - executing more than one statements in the same batch. A
> >    synchronous executions.
> >    Examples:
> >        cd ./test_dir ; tar -czvf ../test_dir.tar.gz *
> >
>
> &&  - conditional execution
>
>
> The following section is better be given after variables (IMHO)
>
> >
> > - The "(" .. ")" - grouping statements inside a _subshell_ (separate
> > process).
> >    Examples:
> >        (cd ./bin ; ls d* ) > files_in_bin_that_start_with_a_d.txt
>
> {}  - same process
>

Interesting, I did not know that, as I use ( .. ) most of the time.

> put {} and give it a name - function.
>
> Differences:  exported variables vs non-exported variables.
>
> A=1
> B=2
> export A
> {
>   echo A is ${A:-"unset"}
>   echo B is ${B:-"unset"}
> }
> (
>   echo A is ${A:-"unset"}
>   echo B is ${B:-"unset"}
> )
>
> Control structures:
>
> do ; done - a block
>
> if ; then ; fi
> while
> for atom in lat
>

I'm not finished with the lecture summary. I am going to cover loops,
conditionals, etc. but later on.

>
> >
> > - Using the backslash (with no whitespace afterwards) to split
> > commands across
> >   several lines. Eases readability:
> >    Examples:
> >        cp *.c *.h README Makefile TODO \
> >            USAGE INSTALL \
> >                ./bak
> >
> > - Introducing comments with "#". They start with a # and extend to the
> > end of
> >   the line.
> >
> > Variables:
> > ----------
> >
> > - Simple assignment: "=". (note that there cannot be any whitespace before
> > and after the "=" symbol.)
> >    Examples:
> >    A=hello
> >    B=yellow ; turn=500
> >
> > - Retrieving the value of a variable using $ or ${} . (not $() !)
> >    Examples:
> >        - A=hello
> >          echo $A
> >        - VARIABLE=5
> >          B=${VARIABLE}
> >          VARIABLE=800
> >          echo $B
> >        - A=Y
> >          Y=80
> >          echo ${$A}
> >
> > - A little about extrapolation: A dollar can appear anywhere. If the shell
> >   encounters a $ which is not followed by curly brackets ("{" .. "}")
> > it will
> >   try to extroplate its name from as many characters as it find, even if
> >   a variable by that name does not exist. Thus, when in doubt, use the
> >   "${NAME}" form.
> >
> >    Examples:
> >        - A=hello
> >          echo $Aworld
> >          # does not print helloworld
> >
> >
> > - The "${parameter:-defaultvalue}" form enables you to give the
> > expression a
> >   default value in case the variable is not assigned.
> >    Examples:
> >        -
> >            #!/bin/bash
> >
> >            ;
> >            ; Possibly set A
> >            B=${A:-not_set}
> >            ; Check if B is equal to not_set and accordingly do something.
> >
> > - To unset a variable use the "unset" command:
> >    Examples:
> >        -
> >            #!/bin/bash
> >            A=5
> >            B=80
> >            RESULT=400
> >            echo $A \* $B = $RESULT
> >            unset A B RESULT
> >
> > - To display a list of the declared variables and their values, use
> > the "set"
> >   command without any options. (set is of little use in scripts except for
> >   debugging purposes).
> >
> >   Examples:
> >     -
> >        A=32482 ; B=932840 ; C=1932840 ; D=890 ; E=hello ; F=world
> >        unset A E
> >        set | grep '^[A-F]='
> >
> > - The "read VARNAME" command reads a line from the standard output and
> > puts
> >   it inside the variable "VARNAME".
> >    - Note: Do not use "read $VARNAME"!
>
> Actualy, read $VARNAME is legal...
>

I know, maybe I should show them this code:
A=B
B=A
read $A
echo A
echo B

to demonstrate what it does.

> >
> >
> >   Examples:
> >
>
> `` and $() program substitution.
> Why it is better to use $()
> Example:
> $( cd  $( echo "/usr" ) && pwd )  instead of
> `cd \`echo "/usr"\' && pwd`
>

Like I said I am going to cover it just later on. And I know $() is
usually better than ``.

Regards,

	 Shlomi Fish


----------------------------------------------------------------------
Shlomi Fish        shlomif@...
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       shlomif@...

The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.

SchemeOS development team has decided to abandon SchemeOS and try to use
the design ideas in the context of vapour. Vapour ca be found at
sourceforge.net.


--
Moshe Zadka <moshez@...> -- 95855124
http://advogato.org/person/moshez

On Wed, Nov 01, 2000, Shlomi Fish wrote about "Re: [hackers-il] Summary of a
Bash Lecture":
> I'm not planning to cover readline too much in the lecture, because:
> 1. It has lots of options, most of which I never use.
> 2. Most users are familiar with its basic options (tab, up and down
> arrows, etc.)
> 3. I want my lecture to be as sh (ash) complaint as possible and the use
> of readline is unique to bash and zsh.

Just a small correction: readline is a GNU library which any interactive
program can use to support line editing and history. Bash uses it, and
gnuplot and bc use it, for example. But neither zsh nor ksh use this library,
and instead use their own implementations (zsh's is called ZLE, the Zsh
Line Editor), so what you explain about readline doesn't directly apply
to zsh or ksh.
You're right that most people will guess the arrow keys (this works on bash and
zsh, but not on ksh which has VI bindings by default), but perhaps tab
completion isn't natural to someone who hasn't used such a shell before.

A propos readline, I once found a program (I still have its source code
lying around) called "ile" that added history to *any* interactive program
(without needed to recompile it). What it did is to define a new pseudo-
terminal, make the program you run output and input into this pty, and ile
controlled the master side adding support for line editing, history, and so
on. It worked very nicely: you could run 'ile cat' and get 'cat' with history
support :) A more realistic example is 'ile hoc' (hoc is a "high order
calculator" originally written by Brian Kernighan, which I enhanced since
1986).
I wonder why nobody wrote something like ile that uses readline, and why
such a thing doesn't come with popular Linux distributions (or maybe such
a thing exists, and I simply don't know about it).

> > >        (cd ./bin ; ls d* ) > files_in_bin_that_start_with_a_d.txt
> >
> > {}  - same process
> >
>
> Interesting, I did not know that, as I use ( .. ) most of the time.

Maybe one of the suggestions to new users should be: read the manual :)
Both bash and zsh have excelent documents, and the "{...}" would be explained
in any shell book (even one from 20 years ago).

> > A=1
> > B=2
> > export A
> > {
> >   echo A is ${A:-"unset"}
> >   echo B is ${B:-"unset"}
> > }
> > (
> >   echo A is ${A:-"unset"}
> >   echo B is ${B:-"unset"}
> > )

Hmm.. Did you actually try this? I don't think this would work like you
think - you won't get any "unset" error.. When the shell forks a subshell,
*all* its memory (including *all* variables, not only exported variables)
gets copied to the subshell.
Only when an external program is "execve"ed do the local variables get erased
from memory, and only the exported variables (the ones that are passed in
the 'environment' string of the process) survive.

> > > - Simple assignment: "=". (note that there cannot be any whitespace before
> > > and after the "=" symbol.)
> > >    Examples:
> > >    A=hello
> > >    B=yellow ; turn=500

You should also explain the
	 A=value command...
syntax, which is very very useful, and doesn't have a csh equivalent.
For example,
	 DISPLAY=remotehost:0.0 xlogo

This syntax creates and exports a variable, but only for running one command
(it is returned to its previous state after running the command).

> > > - The "read VARNAME" command reads a line from the standard output and
> > > puts
> > >   it inside the variable "VARNAME".
> > >    - Note: Do not use "read $VARNAME"!
> >
> > Actualy, read $VARNAME is legal...
> >
>
> I know, maybe I should show them this code:
> A=B
> B=A
> read $A
> echo A
> echo B
>
> to demonstrate what it does.

This discussion seems a bit exessive to me. Just say that "read A" is the
correct syntax... I mean, you also said that to assign a variable you do
A=3. What happens if somebody does $A=3? It's the same problem, and I see
no reason to talk about it much. That is, unless your listeners are Perl
experts, and are used to that $ everywhere :)

By the way, you fell into the same trap yourself - I think you meant "echo $A"
and "echo $B", not "echo A", "echo B"...

> > `` and $() program substitution.
> > Why it is better to use $()
> > Example:
> > $( cd  $( echo "/usr" ) && pwd )  instead of
> > `cd \`echo "/usr"\' && pwd`
> >
>
> Like I said I am going to cover it just later on. And I know $() is
> usually better than ``.

I'm not sure "usually" is the correct word... For interactive use, the
backticks (grave accents) are easier because they're one less character to
type, and don't need to press the shift key. And they're the only command
substitution you had in the original Bourne Shell (not that this really
matters now... Even ash supports $(...) ).

--
Nadav Har'El                        |    Wednesday, Nov 1 2000, 3 Heshvan 5761
nyh@...             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |(On the back of a VW Beetle) Don't honk,
http://nadav.harel.org.il           |I'm peddling as fast as I can.

Nadav Har'El wrote:

> On Wed, Nov 01, 2000, Shlomi Fish wrote about "Re: [hackers-il] Summary of a
Bash Lecture":
>
>> I'm not planning to cover readline too much in the lecture, because:
>> 1. It has lots of options, most of which I never use.
>> 2. Most users are familiar with its basic options (tab, up and down
>> arrows, etc.)
>> 3. I want my lecture to be as sh (ash) complaint as possible and the use
>> of readline is unique to bash and zsh.
>
> Just a small correction: readline is a GNU library which any interactive
> program can use to support line editing and history. Bash uses it, and
> gnuplot and bc use it, for example. But neither zsh nor ksh use this library,
> and instead use their own implementations (zsh's is called ZLE, the Zsh
> Line Editor), so what you explain about readline doesn't directly apply
> to zsh or ksh.
> You're right that most people will guess the arrow keys (this works on bash
and
> zsh, but not on ksh which has VI bindings by default), but perhaps tab
> completion isn't natural to someone who hasn't used such a shell before.
>
> A propos readline, I once found a program (I still have its source code
> lying around) called "ile" that added history to *any* interactive program
> (without needed to recompile it). What it did is to define a new pseudo-
> terminal, make the program you run output and input into this pty, and ile
> controlled the master side adding support for line editing, history, and so
> on. It worked very nicely: you could run 'ile cat' and get 'cat' with history
> support :) A more realistic example is 'ile hoc' (hoc is a "high order
> calculator" originally written by Brian Kernighan, which I enhanced since
> 1986).

Wow:)) thats very nice:)

> I wonder why nobody wrote something like ile that uses readline, and why
> such a thing doesn't come with popular Linux distributions (or maybe such
> a thing exists, and I simply don't know about it).
>
>
>>>>        (cd ./bin ; ls d* ) > files_in_bin_that_start_with_a_d.txt
>>>
>>> {}  - same process
>>>
>>
>> Interesting, I did not know that, as I use ( .. ) most of the time.
>
> Maybe one of the suggestions to new users should be: read the manual :)
> Both bash and zsh have excelent documents, and the "{...}" would be explained
> in any shell book (even one from 20 years ago).
>
>
>>> A=1
>>> B=2
>>> export A
>>> {
>>>   echo A is ${A:-"unset"}
>>>   echo B is ${B:-"unset"}
>>> }
>>> (
>>>   echo A is ${A:-"unset"}
>>>   echo B is ${B:-"unset"}
>>> )
>>
> Hmm.. Did you actually try this? I don't think this would work like you
> think - you won't get any "unset" error.. When the shell forks a subshell,
> *all* its memory (including *all* variables, not only exported variables)
> gets copied to the subshell.
> Only when an external program is "execve"ed do the local variables get erased
> from memory, and only the exported variables (the ones that are passed in
> the 'environment' string of the process) survive.

Ooops.  My mistake.

>>>> - Simple assignment: "=". (note that there cannot be any whitespace before
>>>> and after the "=" symbol.)
>>>>    Examples:
>>>>    A=hello
>>>>    B=yellow ; turn=500
>>>
> You should also explain the
>  A=value command...
> syntax, which is very very useful, and doesn't have a csh equivalent.
> For example,
>  DISPLAY=remotehost:0.0 xlogo
>
> This syntax creates and exports a variable, but only for running one command
> (it is returned to its previous state after running the command).
>
>
>>>> - The "read VARNAME" command reads a line from the standard output and
>>>> puts
>>>>   it inside the variable "VARNAME".
>>>>    - Note: Do not use "read $VARNAME"!
>>>
>>> Actualy, read $VARNAME is legal...
>>>
>>
>> I know, maybe I should show them this code:
>> A=B
>> B=A
>> read $A
>> echo A
>> echo B
>>
>> to demonstrate what it does.
>
> This discussion seems a bit exessive to me. Just say that "read A" is the
> correct syntax... I mean, you also said that to assign a variable you do
> A=3. What happens if somebody does $A=3? It's the same problem, and I see
> no reason to talk about it much. That is, unless your listeners are Perl
> experts, and are used to that $ everywhere :)
>
> By the way, you fell into the same trap yourself - I think you meant "echo $A"
> and "echo $B", not "echo A", "echo B"...
>
>
>>> `` and $() program substitution.
>>> Why it is better to use $()
>>> Example:
>>> $( cd  $( echo "/usr" ) && pwd )  instead of
>>> `cd \`echo "/usr"\' && pwd`
>>>
>>
>> Like I said I am going to cover it just later on. And I know $() is
>> usually better than ``.
>
> I'm not sure "usually" is the correct word... For interactive use, the
> backticks (grave accents) are easier because they're one less character to
> type, and don't need to press the shift key. And they're the only command
> substitution you had in the original Bourne Shell (not that this really
> matters now... Even ash supports $(...) ).
>

Besides that,

eval may be intriguing and very useful

On Wed, 1 Nov 2000, Nadav Har'El wrote:

> > > >        (cd ./bin ; ls d* ) > files_in_bin_that_start_with_a_d.txt
> > >
> > > {}  - same process
> > >
> >
> > Interesting, I did not know that, as I use ( .. ) most of the time.
>
> Maybe one of the suggestions to new users should be: read the manual :)
> Both bash and zsh have excelent documents, and the "{...}" would be explained
> in any shell book (even one from 20 years ago).
>

Good point. I'll keep that in mind.

> > > > - The "read VARNAME" command reads a line from the standard output and
> > > > puts
> > > >   it inside the variable "VARNAME".
> > > >    - Note: Do not use "read $VARNAME"!
> > >
> > > Actualy, read $VARNAME is legal...
> > >
> >
> > I know, maybe I should show them this code:
> > A=B
> > B=A
> > read $A
> > echo A
> > echo B
> >
> > to demonstrate what it does.
>
> This discussion seems a bit exessive to me. Just say that "read A" is the
> correct syntax... I mean, you also said that to assign a variable you do
> A=3. What happens if somebody does $A=3? It's the same problem, and I see
> no reason to talk about it much. That is, unless your listeners are Perl
> experts, and are used to that $ everywhere :)
>
> By the way, you fell into the same trap yourself - I think you meant "echo $A"
> and "echo $B", not "echo A", "echo B"...
>

You are right. It should be "echo $A" and "echo $B".

> > > `` and $() program substitution.
> > > Why it is better to use $()
> > > Example:
> > > $( cd  $( echo "/usr" ) && pwd )  instead of
> > > `cd \`echo "/usr"\' && pwd`
> > >
> >
> > Like I said I am going to cover it just later on. And I know $() is
> > usually better than ``.
>
> I'm not sure "usually" is the correct word... For interactive use, the
> backticks (grave accents) are easier because they're one less character to
> type, and don't need to press the shift key. And they're the only command
> substitution you had in the original Bourne Shell (not that this really
> matters now... Even ash supports $(...) ).
>

I'll tell users about both forms and explain the pros and cons of both.

	 Shlomi Fish

----------------------------------------------------------------------
Shlomi Fish        shlomif@...
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       shlomif@...

The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.

On Wed, 1 Nov 2000, Omer Mussaev wrote:

>
> Besides that,
>
> eval may be intriguing and very useful
>

I am going to cover eval at a later stage.

I once had to use it. I wanted to write a program that loads all the
modules my soundcard needed to operate, and I insisted on doing it using
insmod. I then wanted that when invoked as "/etc/rc.d/init.d/sound_modules
stop" it would remove them. My problem was that some of the module names
contained whitespace (because of the module parameters). So the only way I
found in order to process them in reverse topological order was to
use eval. I think I still have the script somewhere.

The moral of the story is: use modprobe!

Regards,

	 Shlomi Fish

>
> To unsubscribe from this group, send an email to:
> hackers-il-unsubscribe@egroups.com
>
>
>
>



----------------------------------------------------------------------
Shlomi Fish        shlomif@...
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       shlomif@...

The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.

> The moral of the story is: use modprobe!

Or in Generalized form:

Never implement yourself using shell what is already implemented with C.

I opened a mailing-list to discuss the Extended SQL initiative, which aims
to extend the SQL standard so there actually will be significant database
compatiblity.

To subscribe to it, write a letter to:

x-sql-subscribe@egroups.com

The mailing-list homepage is:

http://www.egroups.com/group/x-sql

A homepage, where we store our RFCs, conclusions, recommendations, etc.
will be up shortly. (I need to ask Ira to allocate an x-sql.iglu.org.il
domain).

I'd like to gain some momentum in the list before I publicize it in
broader open-source circles such as Slashdot, LWN, etc.

You are welcome to join and happy standarizing!

	 Shlomi Fish



----------------------------------------------------------------------
Shlomi Fish        shlomif@...
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       shlomif@...

The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.

> I'd like to gain some momentum in the list before I publicize it in
> broader open-source circles such as Slashdot, LWN, etc.
>You are welcome to join and happy standarizing!

I was wondering, anyonw knows of any case where an Open-Source oriented
group set a standard that became widely used in the commercial world?

Well, you can find it on the lecture's homepage:

http://vipe.technion.ac.il/~shlomif/lecture/Bash/

But since people here seem to like it being posted and replied to, so
its text is included below.

Changes:
- Some typos and mistakes fixed.
- Adding section about quoting and backslashing.

Regards,

	 Shlomi Fish


Summary of sh/Bash Lecture:
------------------------

- Executing simple commands: command name followed by parameters
     Examples:
         ls
         ls -l
         cp test.pl old_test.pl

- Filename Matching mechanisms:
     *
     []
     ?
     Examples:
         ls -l *.c
         cp *.c ./bak_dir

- Pipeline: explain a little about standard input/standard output, then
show
     the following redirection mechanisms:
     |
     >
     <
     Examples:
         ls -l | less
         cat *.c *h | wc -l
         ls -l | grep ^d | wc -l

- The ";" - executing more than one statements in the same batch. A
     synchronous executions.
     Examples:
         cd ./test_dir ; tar -czvf ../test_dir.tar.gz *

- The "(" .. ")" - grouping statements inside a _subshell_ (separate
process).
     Examples:
         ( cd ./bin ; ls d* ) > files_in_bin_that_start_with_a_d.txt

- The "{" .. "}" - grouping statement in the same shell (not a separate
   process).
     Examples:
         { cd ./bin ; ls d* } > files_in_bin_that_start_with_a_d.txt

- Using the backslash (with no whitespace afterwards) to split commands
across
   several lines. Eases readability:
     Examples:
         cp *.c *.h README Makefile TODO \
             USAGE INSTALL \
                 ./bak

- Introducing comments with "#". They start with a # and extend to the end
of
   the line.

Variables:
----------

- Simple assignment: "=". (note that there cannot be any whitespace before
and after the "=" symbol.)
     Examples:
     A=hello
     B=yellow ; turn=500

- Retrieving the value of a variable using $ or ${} . (not $() !)
     Examples:
         - A=hello
           echo $A
         - VARIABLE=5
           B=${VARIABLE}
           VARIABLE=800
           echo $B
         - A=Y
           Y=80
           echo ${$A}

- A little about interpolation: A dollar can appear anywhere. If the shell
   encounters a $ which is not followed by curly brackets ("{" .. "}") it
will
   try to interpolate its name from as many characters as it find, even if
   a variable by that name does not exist. Thus, when in doubt, use the
   "${NAME}" form.

     Examples:
         - A=hello
           echo $Aworld
           # does not print helloworld


- The "${parameter:-defaultvalue}" form enables you to give the expression
a
   default value in case the variable is not assigned.
     Examples:
         -
             #!/bin/bash

             ;
             ; Possibly set A
             B=${A:-not_set}
             ; Check if B is equal to not_set and accordingly do something.

- To unset a variable use the "unset" command:
     Examples:
         -
             #!/bin/bash
             A=5
             B=80
             RESULT=400
             echo $A \* $B = $RESULT
             unset A B RESULT

- To display a list of the declared variables and their values, use the
"set"
   command without any options. (set is of little use in scripts except for
   debugging purposes).

   Examples:
      -
         A=32482 ; B=932840 ; C=1932840 ; D=890 ; E=hello ; F=world
         unset A E
         set | grep '^[A-F]='

- The "read VARNAME" command reads a line from the standard output and
puts
   it inside the variable "VARNAME".
     Examples:
         echo "Please enter your name:"
         read NAME
         echo Hello $NAME


     - Note: Be careful not to use "read $VARNAME" when it's not
appropriate.
         For example:
             #!/bin/sh
             A=B
             B=A
             read $A
             echo A is $A
             echo B is $B

Quoting, Backslashing and other animals
---------------------------------------

- A backslash before a character denotes an "actual" character. Hence
means,
   it cannot be processed by the shell.
     Examples:
         -
         echo Hello\ \ \ \ \ World        # vs.
         echo Hello     World
         -
         echo good ; echo you
         echo good \; echo you                    # vs.
         -
         echo \\ - This is a backslash


- Use the double quotes to group strings which include whitespaces and
   keywords:
     Examples:
         echo "Hello   World"          # vs.
         echo Hello    World

     Note: double quotes do interpolation. For example:
         #!/bin/sh
         A=Hello
         echo "$A    world!"

- Use the single quotes to group strings which include whitespace, dollars
   and backslashes without doing variable interpolation:
     Examples:
         #!/bin/sh
         A=Hello
         echo '$A    world!'
         echo 'and here's a backslash - \'    # Note that \' is not
considered
                                              # an inner single quote.

- Quotes and regular texts can be arbitrarily combined (but not nested !)
     Examples:
         #!/bin/sh
         myvar="young at heart"
         echo "Some pe"ople are "${myvar}".
         echo 'Me, 'included\!












----------------------------------------------------------------------
Shlomi Fish        shlomif@...
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       shlomif@...

The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.

On Wed, 1 Nov 2000, Chen Shapira wrote:

>
>
> > I'd like to gain some momentum in the list before I publicize it in
> > broader open-source circles such as Slashdot, LWN, etc.
> >You are welcome to join and happy standarizing!
>
> I was wondering, anyonw knows of any case where an Open-Source oriented
> group set a standard that became widely used in the commercial world?
>

The W3C is fairly Open-Source, or at least their standards are publicly
available for free. Anyway, I welcome commercial DB vendors to join the
X-SQL effort so they'll have a voice too.

Also, I'd like people who are experienced in commercial databases to join.
That way I can compare how different databases implement different things,
and try to form a syntax that is at most compatible with everything else
which is already present.

For example, the log() function in MySQL is the natural logarithm and in
Postgres it's the logarithm according to base 10 (or vise versa). Knowing
that I can declare that ln() and log10() should be implemented while log()
should be depreciated.

Regards,

	 Shlomi Fish

>
>
>
> To unsubscribe from this group, send an email to:
> hackers-il-unsubscribe@egroups.com
>
>
>
>



----------------------------------------------------------------------
Shlomi Fish        shlomif@...
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       shlomif@...

The prefix "God Said" has the extraordinary logical property of
converting any statement that follows it into a true one.

> The W3C is fairly Open-Source, or at least their standards
> are publicly
> available for free. Anyway, I welcome commercial DB vendors
> to join the
> X-SQL effort so they'll have a voice too.

It has memebers both from Microsoft and Netscape forming 2/5 of its deciding
board.

What I mean is that by publishing on LWN and /. you may get the agreement of
the opensource community, but not of the Nasdaq community.

On Wed, Nov 01, 2000, Chen Shapira wrote about "RE: [hackers-il] Summary of a
Bash Lecture":
>
> > The moral of the story is: use modprobe!
>
> Or in Generalized form:
>
> Never implement yourself using shell what is already implemented with C.

This is a tautology, and a biased one at that (if you remove the words "shell"
and "C", the sentence will still be true, and all you did was added a bias
against the shell) ;)

But to return to the issue - 'eval': watch out for this command. It is nice
for interactive use, but dangerous (security-wise) for shell-scripts.
For example, consider the following example: You do
	 A=3
	 B=A
and then you want to do something like $$B to get the value 3. Unfortunately,
in neither bash nor zsh none of the "obvious" methods work: $$B, ${$B}, ${${B}}.
(I can explain why these do not work - it's not a bug - but let's forget it now)
So, you decide to do
	 eval echo \$$B

Now, what happens if someone manages to set B to "zzz hello >/etc/passwd"
to "; rm -rf /", or even "(rm -rf /)"? You've guessed it :)
[if you try the above examples, please replace the rm -rf / with something
less harmful! the last example also shows another problem with the $(...)
construction]

So watch out :)

P.S. You can do the above example in zsh as
	 Z=\$$B; echo ${(e)Z}
but this still has the problem with evaluating also the dangerous $(...).


--
Nadav Har'El                        |    Wednesday, Nov 1 2000, 4 Heshvan 5761
nyh@...             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Linux is just like a wigwam: no Windows,
http://nadav.harel.org.il           |no Gates and an Apache inside.

On Wed, 1 Nov 2000, Chen Shapira wrote:

>
> > The moral of the story is: use modprobe!
>
> Or in Generalized form:
>
> Never implement yourself using shell what is already implemented with C.

Though one should not forget the companion lesson: never implement in C,
what can be easily implemented with shell.

the big paradox!
--
Moshe Zadka <moshez@...> -- 95855124
http://advogato.org/person/moshez

both of these can be abstracted as
"use the right tool for the task at hand"
or its negation
"to a man with only a hammer, everything looks like a nail"

which does bring up an interesting questions: assume all tools being
equally suited to the task at end, in that each tool has unique
advantages and disadvantages. how do you choose?

On Wed, 1 Nov 2000, Moshe Zadka wrote:

> On Wed, 1 Nov 2000, Chen Shapira wrote:
>
> > Never implement yourself using shell what is already implemented with C.
>
> Though one should not forget the companion lesson: never implement in C,
> what can be easily implemented with shell.
--
mulix

linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead

On Wed, Nov 01, 2000, mulix wrote about "RE: [hackers-il] Summary of a Bash
Lecture":
>
> both of these can be abstracted as
> "use the right tool for the task at hand"
> or its negation
> "to a man with only a hammer, everything looks like a nail"
>
> which does bring up an interesting questions: assume all tools being
> equally suited to the task at end, in that each tool has unique
> advantages and disadvantages. how do you choose?

Obviously, in some cases it is not clear if it is best to use C, shell,
perl, awk, or whatever. But in many cases one language has a definate
advantage over another. Only if you know all the languages (or a good
selection of them), you'll be able to choose the appropriate one for each
task.

For example, if you want to write a short (say <100 line) program, which
most of its work is to call other external programs and handle string
constants, why use C which is horribly complex with handling strings (and
needing to allocate eveything, etc.)?

Experience is also a factor. For example, I have about 14 years of
experience with Awk, but only about 3 years with Perl, so when I want to
write a small (say, 50 lines) string-handling script I instinctively
use Awk, only turning to Perl when I need something bigger or one of Perl's
extra features (e.g., socket programming, HTTP connection, etc.).

The funniest example I've seen is where someone I worked with wanted to
write a program which interpolates "include" commands into Fortran source
code (kind of like the C preprocessor's #include). Since Fortran is the
only language he knew well (and I'm talking about Fortran 77, not the
newer C-wannabe-Fortran-90) he wrote this program in Fortran. What could
have been a ~50 line awk script (for example) turned out a hillarious
Fortran program with several hundreds of lines and limitations that only
Fortran addicts will understand (e.g., source lines were not copied as is,
but instead filled with spaces to be 72 character wide, or truncated after
the 72nd character - this is because Fortran doesn't have variable-length
strings (!)).

--
Nadav Har'El                        |    Wednesday, Nov 1 2000, 4 Heshvan 5761
nyh@...             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |When everything's coming your way,
http://nadav.harel.org.il           |you're in the wrong lane.

On Wed, Nov 01, 2000 at 07:48:03PM +0200, Chen Shapira wrote:
> > I'd like to gain some momentum in the list before I publicize it in
> > broader open-source circles such as Slashdot, LWN, etc.
> >You are welcome to join and happy standarizing!
>
> I was wondering, anyonw knows of any case where an Open-Source oriented
> group set a standard that became widely used in the commercial world?

Berkley sockets. And what about X11, by the way?  Was it a similar
story?

Also looks like Jabber is heading in that direction.

On Tue, Oct 31, 2000 at 08:24:17AM +0200, Shlomi Fish wrote:
> I'm considering giving a lecture about Bash to the Haifa Linux Club. I
> started to write a summary of it and you can find it at the following URL:
>
> http://vipe.technion.ac.il/~shlomif/lecture/Bash/
>
> If you wish, read it and send your comments, either personally to me or to
> the list.

If you're mentioning ';', you might as well mention '&&' and '||'.


[ conditions ] && command

is very useful and will be familiar to Perl people.


Also brace expansion, e.g. "ls -l {,/usr,/usr/X11R6}/bin/*sh" and why
is it different from filename expansion.

On Wed, 1 Nov 2000, Nadav Har'El wrote:

> Now, what happens if someone manages to set B to "zzz hello >/etc/passwd"
> to "; rm -rf /", or even "(rm -rf /)"? You've guessed it :)
> [if you try the above examples, please replace the rm -rf / with something
> less harmful! the last example also shows another problem with the $(...)
> construction]

Actually, rm -rf / is not that harmful: as long as anyone remembers
never to try out shell code he's not sure of as root, there's plenty
of time to CTRL-C

--
Moshe Zadka <moshez@...> -- 95855124
http://advogato.org/person/moshez

> > Never implement yourself using shell what is already
> implemented with C.
>
> This is a tautology, and a biased one at that (if you remove
> the words "shell"
> and "C", the sentence will still be true, and all you did was
> added a bias
> against the shell) ;)

not necessarily - if something is implemented in C - you may be able to do a
better job implementing it in C yourself.
Same thing if something is in shell.
But you can't outperform a C program with shell.
Although if something was written in shell, you may want to implement it
again with C for performance issues.

Which means - if I reverse "shell" and "C" we no longer have a true
sentence, so its not a tautology.

Which reminds me, does anyone has used math books from previous years in the
university that he/she can sell/lend?

On Thu, Oct 26, 2000 at 06:15:09PM +0200, Chen Shapira wrote:
> To all hard-core hackers claiming that using the keyboard is much faster

In case you haven't read it yet, take a look at Neal Stephenson's
essay, In the Beginning was the Comamnd Line. It has been published
in book form (Hearst, 1999), but is also available online at:

http://www.cryptonomicon.com/beginning.html

--
Gaal Yahas <gaal@...>

> > Never implement yourself using shell what is already
> implemented with C.
>
> Though one should not forget the companion lesson: never
> implement in C,
> what can be easily implemented with shell.
>
> the big paradox!

Not really.
C is most usefull when someone else already implemented it for you :-)
And when you have purify at hand.

Which reminds me of 2 projects I wanted to look into:

1) Open Source equivilent of Rational's Purify.
2) Purify for garbage collecting languages.
Ofcource GC languages can't do evil memory violations, but we can do what we
call "misuse of system resources". meaning: running out of resources that
are not GCed like file-handles and db connections, and even things like
constantly writing long strings into a variable can cause system to fail
memory. I'd like to have a program that pointed things out and said - "This
looks wierd, it can cause Y and Z to happen, are you sure its ok?"

>
> which does bring up an interesting questions: assume all tools being
> equally suited to the task at end, in that each tool has unique
> advantages and disadvantages. how do you choose?

if you have the same knowledge and experience in both, and both are 100%
fitting to the task, you can consider the following things:

1) maintainability: write it in a language most likely others can work with
2) better compiler/run-time enviroment
3) buzzword compatible. if you have the time - do it in java not python.
Clients think it sounds better.
4) Random bias. I like writing in Jscript.
5) Look-ahead: if you write it in VB - you can't run it on Sun!
6) Monte-Carlo method?
7) Cute features. Jscript has sucky date object - but I can get Unix time in
windows in one command.
8) Cute bugs. VB implements arrays with linked lists. They take forever to
work with. I actually implement arrays in C, and stick them in as DLL's into
VB programs to get 500% increase in performance.

On Wed, 1 Nov 2000, mulix wrote:

>
> both of these can be abstracted as
> "use the right tool for the task at hand"
> or its negation
> "to a man with only a hammer, everything looks like a nail"
>
> which does bring up an interesting questions: assume all tools being
> equally suited to the task at end, in that each tool has unique
> advantages and disadvantages. how do you choose?

Ummmmmm.....weigh which advantages and disadvantages are most crucial,
based on my previous experiences?

Which is another way of saying that there is no such situations: in every
situation there is one tool most suited. Which tool it is depends on many
factors, and is the nexus of many flamewars (Python/Perl/Tcl, Emacs/vi,
Linux/FreeBSD, Lisp/Scheme and so on).

--
Moshe Zadka <moshez@...> -- 95855124
http://advogato.org/person/moshez