* named directory expansion on strings @ 2004-03-13 3:29 Thorsten Kampe 2004-03-13 6:41 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Thorsten Kampe @ 2004-03-13 3:29 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: named directory expansion on strings 2004-03-13 3:29 named directory expansion on strings Thorsten Kampe @ 2004-03-13 6:41 ` Bart Schaefer 2004-03-13 17:48 ` Thorsten Kampe 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2004-03-13 6:41 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: named directory expansion on strings 2004-03-13 6:41 ` Bart Schaefer @ 2004-03-13 17:48 ` Thorsten Kampe 2004-03-14 18:54 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Thorsten Kampe @ 2004-03-13 17:48 UTC (permalink / raw) To: zsh-users * 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! `--- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: named directory expansion on strings 2004-03-13 17:48 ` Thorsten Kampe @ 2004-03-14 18:54 ` Bart Schaefer 2004-03-14 21:24 ` Thorsten Kampe ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Bart Schaefer @ 2004-03-14 18:54 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: named directory expansion on strings 2004-03-14 18:54 ` Bart Schaefer @ 2004-03-14 21:24 ` Thorsten Kampe 2004-03-14 21:57 ` Python/zsh/perl [was: named directory expansion on strings] Vincent Stemen 2004-03-14 22:19 ` named directory expansion on strings Thorsten Kampe 2 siblings, 0 replies; 12+ messages in thread From: Thorsten Kampe @ 2004-03-14 21:24 UTC (permalink / raw) To: zsh-users * 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Python/zsh/perl [was: named directory expansion on strings] 2004-03-14 18:54 ` Bart Schaefer 2004-03-14 21:24 ` Thorsten Kampe @ 2004-03-14 21:57 ` Vincent Stemen 2004-03-15 4:00 ` Jos Backus 2004-03-15 7:04 ` [OT]Python/zsh/perl " Bob Schmertz 2004-03-14 22:19 ` named directory expansion on strings Thorsten Kampe 2 siblings, 2 replies; 12+ messages in thread From: Vincent Stemen @ 2004-03-14 21:57 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Python/zsh/perl [was: named directory expansion on strings] 2004-03-14 21:57 ` Python/zsh/perl [was: named directory expansion on strings] Vincent Stemen @ 2004-03-15 4:00 ` Jos Backus 2004-03-15 7:04 ` [OT]Python/zsh/perl " Bob Schmertz 1 sibling, 0 replies; 12+ messages in thread From: Jos Backus @ 2004-03-15 4:00 UTC (permalink / raw) To: zsh-users 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' ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OT]Python/zsh/perl [was: named directory expansion on strings] 2004-03-14 21:57 ` Python/zsh/perl [was: named directory expansion on strings] Vincent Stemen 2004-03-15 4:00 ` Jos Backus @ 2004-03-15 7:04 ` Bob Schmertz 2004-03-15 23:37 ` [OT]Python/zsh/perl Vincent Stemen 2004-03-17 4:03 ` [OT]Python/zsh/perl [was: named directory expansion on strings] Eric Mangold 1 sibling, 2 replies; 12+ messages in thread From: Bob Schmertz @ 2004-03-15 7:04 UTC (permalink / raw) To: Vincent Stemen, zsh-users --- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OT]Python/zsh/perl 2004-03-15 7:04 ` [OT]Python/zsh/perl " Bob Schmertz @ 2004-03-15 23:37 ` Vincent Stemen 2004-03-17 4:03 ` [OT]Python/zsh/perl [was: named directory expansion on strings] Eric Mangold 1 sibling, 0 replies; 12+ messages in thread From: Vincent Stemen @ 2004-03-15 23:37 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OT]Python/zsh/perl [was: named directory expansion on strings] 2004-03-15 7:04 ` [OT]Python/zsh/perl " Bob Schmertz 2004-03-15 23:37 ` [OT]Python/zsh/perl Vincent Stemen @ 2004-03-17 4:03 ` Eric Mangold 1 sibling, 0 replies; 12+ messages in thread From: Eric Mangold @ 2004-03-17 4:03 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: named directory expansion on strings 2004-03-14 18:54 ` Bart Schaefer 2004-03-14 21:24 ` Thorsten Kampe 2004-03-14 21:57 ` Python/zsh/perl [was: named directory expansion on strings] Vincent Stemen @ 2004-03-14 22:19 ` Thorsten Kampe 2004-03-14 23:19 ` Bart Schaefer 2 siblings, 1 reply; 12+ messages in thread From: Thorsten Kampe @ 2004-03-14 22:19 UTC (permalink / raw) To: zsh-users * 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: named directory expansion on strings 2004-03-14 22:19 ` named directory expansion on strings Thorsten Kampe @ 2004-03-14 23:19 ` Bart Schaefer 0 siblings, 0 replies; 12+ messages in thread From: Bart Schaefer @ 2004-03-14 23:19 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-03-17 3:40 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-03-13 3:29 named directory expansion on strings Thorsten Kampe 2004-03-13 6:41 ` Bart Schaefer 2004-03-13 17:48 ` Thorsten Kampe 2004-03-14 18:54 ` Bart Schaefer 2004-03-14 21:24 ` Thorsten Kampe 2004-03-14 21:57 ` Python/zsh/perl [was: named directory expansion on strings] Vincent Stemen 2004-03-15 4:00 ` Jos Backus 2004-03-15 7:04 ` [OT]Python/zsh/perl " Bob Schmertz 2004-03-15 23:37 ` [OT]Python/zsh/perl Vincent Stemen 2004-03-17 4:03 ` [OT]Python/zsh/perl [was: named directory expansion on strings] Eric Mangold 2004-03-14 22:19 ` named directory expansion on strings Thorsten Kampe 2004-03-14 23:19 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).