named directory expansion on strings

named directory expansion on strings

[Thorsten Kampe]

Is there a way to perform "named directory" expansion on strings?
Something like "autonamedirs" and the "%~" in the prompt...

% file=/etc/foo
% ETCDIR=/etc
% echo `bar#!$whatever($file)`
~ETCDIR/foo
%

Thorsten

Re: named directory expansion on strings

[Bart Schaefer]

On Mar 13,  4:29am, Thorsten Kampe wrote:
}
} Is there a way to perform "named directory" expansion on strings?

Sort of.  See "print" in "man zshbuiltins" and look at the -D option.

} Something like "autonamedirs" and the "%~" in the prompt...
} 
} % file=/etc/foo
} % ETCDIR=/etc
} % echo `bar#!$whatever($file)`

I take it that the stuff in backticks is something that you just made up
to represent an arbitrary cryptic zsh incantation?

} ~ETCDIR/foo

You'd never get that in this particular example.  "ETCDIR" has six letters,
plus the tilde makes seven.  "/etc" has four letters.  Zsh always chooses
whichever one is shorter.

If you did

% setopt auto_name_dirs
% file=/etc/foo
% E=/etc
% print -D $file

Then you'd get

~E/foo

because ~E has only two letters.

Re: named directory expansion on strings

[Thorsten Kampe]

* Bart Schaefer (2004-03-13 07:41 +0100)
> On Mar 13,  4:29am, Thorsten Kampe wrote:
> } Is there a way to perform "named directory" expansion on strings?
> 
> Sort of.  See "print" in "man zshbuiltins" and look at the -D option.

Yes, this was the reason why I asked. The "-D" option made the output
for my "zcompile" script more readable, but it defeated the adjustment
of my "[ ok ]" because it made a difference whether "~" was
substituted in the path or not. So I wanted to compute the length of
the output to compensate the "adjustment" to the right.

Fortunately, I found a better way[1]. Any style comments on my first
/really complicated/ ;-) zsh shell script welcome!
 
> } Something like "autonamedirs" and the "%~" in the prompt...
> } 
> } % file=/etc/foo
> } % ETCDIR=/etc
> } % echo `bar#!$whatever($file)`
> 
> I take it that the stuff in backticks is something that you just made up
> to represent an arbitrary cryptic zsh incantation?

Yes. Unfortunately when making more complex zsh scripts it tends to go
into the perl direction: code that has to be decrypted by an
inaugurated before it makes sense. And even then it's: "no, no, I
wrote '#.(' and not '.#(' which does something completely different".
Long live the Zen of Python[2].
 
Thorsten

[1] 
,---
| #! /bin/zsh -f
| emulate -LR zsh
| 
| JUSTIFY=71
| 
| autoload -U colors
| colors  # zshcontrib(1)
| 
| ltgreen=$fg_bold[green]
| ltred=$fg_bold[red]
| white=$fg_no_bold[white]
| 
| for file in /etc/profile.d/zshell.zsh \
|             /etc/zsh/zprofile         \
|             /etc/zprofile             \
|             ~/.zsh/.zlogin            \
|             ~/.zsh/.zshrc             \
|             ~/.zshenv
| do
|    if   [[ -e $file && ! -w $(dirname $file) ]]; then
|         print ${(r.$JUSTIFY.):-"${ltred}! ${white}ERROR:    $file - directory not writable"} \
|               "[ ${ltred}failed ${white}]"
|    elif [[ -r $file && -w $(dirname $file) ]]; then
|         # '$(print -D)' instead of simple 'print -D' because padding isn't aware
|         # of "~" named directory expansion in length calculation
|         print ${(r.$JUSTIFY.):-"${ltgreen}* ${white}compiling $(print -D $file)"}            \
|               "[ ${ltgreen}ok ${white}]"
|         zcompile -R $file
|    fi
| done
`---
[2]
,---
| Beautiful is better than ugly.
| Explicit is better than implicit.
| Simple is better than complex.
| Complex is better than complicated.
| Flat is better than nested.
| Sparse is better than dense.
| Readability counts.
| Special cases aren't special enough to break the rules.
| Although practicality beats purity.
| Errors should never pass silently.
| Unless explicitly silenced.
| In the face of ambiguity, refuse the temptation to guess.
| There should be one-- and preferably only one --obvious way to do it.
| Although that way may not be obvious at first unless you're Dutch.
| Now is better than never.
| Although never is often better than *right* now.
| If the implementation is hard to explain, it's a bad idea.
| If the implementation is easy to explain, it may be a good idea.
| Namespaces are one honking great idea -- let's do more of those!
`---

Re: named directory expansion on strings

[Bart Schaefer]

On Mar 13,  6:48pm, Thorsten Kampe wrote:
:
: Fortunately, I found a better way[1]. Any style comments on my first
: /really complicated/ ;-) zsh shell script welcome!

Nothing major ...

: | for file in /etc/profile.d/zshell.zsh \
: |             /etc/zsh/zprofile         \
: |             /etc/zprofile             \
: |             ~/.zsh/.zlogin            \
: |             ~/.zsh/.zshrc             \
: |             ~/.zshenv
: | do
     ...
: | done

If you want to list every name on its own line like that, you might try
the parenthesized list syntax:

    for file (
	/etc/profile.d/zshell.zsh
	/etc/zsh/zprofile
	/etc/zprofile
	~/.zsh/.zlogin
	~/.zsh/.zshrc
	~/.zshenv
      )
    do
     ...
    done

Not compatible with non-zsh shells, of course.  Also works with the
word "foreach", in which case you may omit the "do" and replace "done"
with "end" (syntax stolen from csh).

: |         print ${(r.$JUSTIFY.):-"${ltred}! ${white}..."

You don't need $JUSTIFY there: (r.JUSTIFY.) is sufficient, because the
expression is interpreted in math context where all non-keywords are
variable references.

: Long live the Zen of Python[2].

Hrm.  As far as I'm concerned, the Python folks went wrong when they gave
semantic significance to depth of whitespace indentation, and all of the
right decisions they've made since have been a waste of effort.

Re: named directory expansion on strings

[Thorsten Kampe]

* Bart Schaefer (2004-03-14 19:54 +0100)
> On Mar 13,  6:48pm, Thorsten Kampe wrote:
>: Fortunately, I found a better way[1]. Any style comments on my first
>: /really complicated/ ;-) zsh shell script welcome!
> 
> Nothing major ...
> 
> [...]

Thanks for the tips.

>: Long live the Zen of Python[2].
> 
> Hrm.  As far as I'm concerned, the Python folks went wrong when they gave
> semantic significance to depth of whitespace indentation, and all of the
> right decisions they've made since have been a waste of effort.

Interesting. Everyone says that indentation is good and has a semantic
significance for the programmer. And as soon as the compiler is made
to honor this significance they say: "oh, no, give me back my braces,
curls, parentheses and "END"s, "fi"s, "done"s, etc.

Thorsten

Re: Python/zsh/perl [was: named directory expansion on strings]

[Vincent Stemen]

On Sun, Mar 14, 2004 at 06:54:37PM +0000, Bart Schaefer wrote:
> On Mar 13,  6:48pm, Thorsten Kampe wrote:
> : |         print ${(r.$JUSTIFY.):-"${ltred}! ${white}..."
> 
> You don't need $JUSTIFY there: (r.JUSTIFY.) is sufficient, because the
> expression is interpreted in math context where all non-keywords are
> variable references.
> 
> : Long live the Zen of Python[2].
> 
> Hrm.  As far as I'm concerned, the Python folks went wrong when they gave
> semantic significance to depth of whitespace indentation, and all of the
> right decisions they've made since have been a waste of effort.

I agree.  This surprising discovery is the primary reason I never put
any serious consideration into learning Python.  Seems like it would
be a nightmare to fix if you get your indentation messed up (which is
extremely common when juggling code around).  Also, I use the auto
indentation features of xemacs all the time.  I see no way you could
do that without code block delimiters.  Seems like a step backward in
time.

As long as I am here, I thought I would use the opportunity to give
you Z shell developers some more positive feedback :-).

I was very pleased to find that you can do direct array indexing of
single dimensional arrays in zsh.  ie. if x=abcd, then $x[2] = b.
That very feature is most commonly the weakness of tradition shell
script and even Perl that sometimes ends up causing me to write a
routine as an external C program when I am writing a complex script.

As wonderful of a language as Perl is, that is the one limitation I
have found that gives Z shell an advantage, even over Perl, in
situations where that lower level control is needed.  In Perl, it is
far to much unnecessary overhead to split a string on every character,
into a two dimensional array of strings, using the null delimiter, just
gain access to a specific byte of the array.  Then, if you modify the
array, you must re-join the data back into a single string.  All that,
as opposed to just being able to say "$array[$i] = 'x'".

This is about the only complaint I can think of I have ever really had
with Perl.

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
http://www.InetAddresses.net

Re: Python/zsh/perl [was: named directory expansion on strings]

[Jos Backus]

On Sun, Mar 14, 2004 at 03:57:00PM -0600, Vincent Stemen wrote:
> As wonderful of a language as Perl is, that is the one limitation I
> have found that gives Z shell an advantage, even over Perl, in
> situations where that lower level control is needed.  In Perl, it is
> far to much unnecessary overhead to split a string on every character,
> into a two dimensional array of strings, using the null delimiter, just
> gain access to a specific byte of the array.  Then, if you modify the
> array, you must re-join the data back into a single string.  All that,
> as opposed to just being able to say "$array[$i] = 'x'".
> 
> This is about the only complaint I can think of I have ever really had
> with Perl.

lizzy:~% perl -le 'my $a = "abc"; substr($a, 1, 1) = "z"; print $a;' 
azc
lizzy:~% 

-- 
Jos Backus                       _/  _/_/_/      Sunnyvale, CA
                                _/  _/   _/
                               _/  _/_/_/
                          _/  _/  _/    _/
jos at catnook.com        _/_/   _/_/_/          require 'std/disclaimer'

Re: [OT]Python/zsh/perl [was: named directory expansion on strings]

[Bob Schmertz]

--- Vincent Stemen <zsh@hightek.org> wrote:
[quoted text "juggled around" a bit] 

> I agree.  This surprising discovery is the primary reason I never put
> any serious consideration into learning Python.

> I use the auto indentation features of xemacs all the time.  I see no
> way you could do that without code block delimiters.  Seems like a step
> backward in time.

Emacs seems to be the most popular editor for Python programmers.  It
knows when to start a new indent level, because the if, while, class,
etc. lines all end with a colon.  It can't tell when you want to close
the
block, of course, but if you're typing new code, that's a simple matter
of
hitting the backspace key once for every block you want to close out.  I
wouldn't /think/ of coding in Python if I didn't have Emacs or something
equally smart.

> Seems like it would be a nightmare to fix if you get your indentation
> messed up (which is extremely common when juggling code around).

Not sure exactly what you mean by "juggling around"; if you mean cutting
a
section from a file and moving it elsewhere in the file, or to a
different
file, at a point that starts out at a different indent level, there's a
key sequence to add or subtract an indent level from that entire block of
code, so that the pasted code will be consisent with itself as well as
fitting all under the appropriate if statement or whatever.  If you're
talking about code from someone else, esp. via email and things like
that,
then there are more variables, of course.

Do I think blocking by indentation is the greatest thing since sliced
bread?  No.  But I've been surprised to find that it has rarely, if ever,
been a problem for me the way, oh, buffer overflows, objects that appear
to the lame compiler like they might not be instantiated even though they
definitely always are, or not knowing Perl have been.

> I was very pleased to find that you can do direct array indexing of
> single dimensional arrays in zsh.  ie. if x=abcd, then $x[2] = b.
> That very feature is most commonly the weakness of tradition shell
> script and even Perl that sometimes ends up causing me to write a
> routine as an external C program when I am writing a complex script.
> 
[snip]
> This is about the only complaint I can think of I have ever really had
> with Perl.

Funny, Python does this just fine :-)
 >>> a="spam"
 >>> a[3]
 'm'
 >>>



=====
Cheers,
Bob Schmertz

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

Re: [OT]Python/zsh/perl

[Vincent Stemen]

On Sun, Mar 14, 2004 at 11:04:00PM -0800, Bob Schmertz wrote:
> --- Vincent Stemen <zsh@hightek.org> wrote:
> [quoted text "juggled around" a bit] 
> 
> > I agree.  This surprising discovery is the primary reason I never put
> > any serious consideration into learning Python.
> 
> > I use the auto indentation features of xemacs all the time.  I see no
> > way you could do that without code block delimiters.  Seems like a step
> > backward in time.
> 
> Emacs seems to be the most popular editor for Python programmers.  It
> knows when to start a new indent level, because the if, while, class,
> etc. lines all end with a colon.  It can't tell when you want to close
> the
> block, of course, but if you're typing new code, that's a simple matter
> of
> hitting the backspace key once for every block you want to close out.  I
> wouldn't /think/ of coding in Python if I didn't have Emacs or something
> equally smart.

I agree.  Typing new code from scratch is not where I felt there would
be problems.

> > Seems like it would be a nightmare to fix if you get your indentation
> > messed up (which is extremely common when juggling code around).
> 
> Not sure exactly what you mean by "juggling around"; if you mean cutting
> a
> section from a file and moving it elsewhere in the file, or to a
> different
> file, at a point that starts out at a different indent level, there's a

Yes, that is what I meant.

> key sequence to add or subtract an indent level from that entire block of
> code, so that the pasted code will be consisent with itself as well as
> fitting all under the appropriate if statement or whatever.  If you're
> talking about code from someone else, esp. via email and things like
> that,
> then there are more variables, of course.

Yes, I cannot even begin to count the number of times I pasted code
surrounded by other code with different indentation levels and then
lost track of which code went with which block.  With block
delimiters, I very commonly mark a substantial region under xemacs and
tell it to re-indent to automatically fix it all.  Also, I commonly
will be working with code I did not originally write or modifying code
I wrote in the past and have since changed my indentation style.  That
is especially common when learning a new language where you have not
yet refined the style you like best for that language.  It can become
very tedious manually fixing indentation on a large chunk of code,
especially if you accidently change the whole logic flow and break the
program because you made an indentation mistake and are not familiar
enough with the code to easily catch it.

I feel, at least for me, that no block delimiters would likely end up
being a nightmare.  The popularity of python obviously demonstrates
that many people do not agree with me.  At least not yet :-).

> 
> Do I think blocking by indentation is the greatest thing since sliced
> bread?  No.  But I've been surprised to find that it has rarely, if ever,
> been a problem for me the way, oh, buffer overflows, objects that appear
> to the lame compiler like they might not be instantiated even though they
> definitely always are, or not knowing Perl have been.

I would also be surprised to find that that continued to be the case.
I'm not sure I understand the problems with Perl you mention.  I have
written a fair amount of Perl code over the last several years and it
has been very robust for me.

Anyway, I guess we have steered off topic for a Z shell list (sorry
about that everybody). After this, I will try not to promote further
discussion on the matter.

> 
> > I was very pleased to find that you can do direct array indexing of
> > single dimensional arrays in zsh.  ie. if x=abcd, then $x[2] = b.
> > That very feature is most commonly the weakness of tradition shell
> > script and even Perl that sometimes ends up causing me to write a
> > routine as an external C program when I am writing a complex script.
> > 
> [snip]
> > This is about the only complaint I can think of I have ever really had
> > with Perl.
> 
> Funny, Python does this just fine :-)
>  >>> a="spam"
>  >>> a[3]
>  'm'
>  >>>
> 
> =====
> Cheers,
> Bob Schmertz

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
http://www.InetAddresses.net

Re: [OT]Python/zsh/perl [was: named directory expansion on strings]

[Eric Mangold]

On Sun, 14 Mar 2004 23:04:00 -0800 (PST), Bob Schmertz 
<rschmertz@yahoo.com> wrote:

> --- Vincent Stemen <zsh@hightek.org> wrote:
> [quoted text "juggled around" a bit]
>
>> I agree.  This surprising discovery is the primary reason I never put
>> any serious consideration into learning Python.
>
>> I use the auto indentation features of xemacs all the time.  I see no
>> way you could do that without code block delimiters.  Seems like a step
>> backward in time.
>
> Emacs seems to be the most popular editor for Python programmers.  It
> knows when to start a new indent level, because the if, while, class,
> etc. lines all end with a colon.  It can't tell when you want to close
> the
> block, of course, but if you're typing new code, that's a simple matter
> of
> hitting the backspace key once for every block you want to close out.  I
> wouldn't /think/ of coding in Python if I didn't have Emacs or something
> equally smart.
>
>> Seems like it would be a nightmare to fix if you get your indentation
>> messed up (which is extremely common when juggling code around).
>
> Not sure exactly what you mean by "juggling around"; if you mean cutting
> a
> section from a file and moving it elsewhere in the file, or to a
> different
> file, at a point that starts out at a different indent level, there's a
> key sequence to add or subtract an indent level from that entire block of
> code, so that the pasted code will be consisent with itself as well as
> fitting all under the appropriate if statement or whatever.  If you're
> talking about code from someone else, esp. via email and things like
> that,
> then there are more variables, of course.
>
> Do I think blocking by indentation is the greatest thing since sliced
> bread?  No.  But I've been surprised to find that it has rarely, if ever,
> been a problem for me

Yeah. It's a complete non-issue. There are much better things to fault 
python for. (not that having faults makes it a bad choice for various 
things)

Re: named directory expansion on strings

[Thorsten Kampe]

* Bart Schaefer (2004-03-14 19:54 +0100)
> On Mar 13,  6:48pm, Thorsten Kampe wrote:
> Not compatible with non-zsh shells, of course.  Also works with the
> word "foreach", in which case you may omit the "do" and replace "done"
> with "end" (syntax stolen from csh).

The manual says foreach is "deprecated" and should not be used. But
thanks anyway.

Thorsten

Re: named directory expansion on strings

[Bart Schaefer]

On Mar 14, 11:19pm, Thorsten Kampe wrote:
}
} The manual says foreach is "deprecated" and should not be used.

Ah, well, yes, there was a brief period about ten years ago during
which the Zsh Dev Group was seriously considering excising all the
csh features from zsh and making it essentially a ksh clone.  The
manuals got updated then to say a lot of things were "deprecated" and
the tarnish has never been scrubbed off again.

The chances of them actually being removed from the shell are pretty
remote.  They might get moved into a module if we figure out how to
make bits of the parser (un)pluggable, but they probably won't entirely
go away.