* rm nonexisting*; alias with parameters? @ 2005-08-10 19:18 ` Deliverable Mail 2005-08-10 20:06 ` Peter Stephenson 0 siblings, 1 reply; 10+ messages in thread From: Deliverable Mail @ 2005-08-10 19:18 UTC (permalink / raw) To: zsh-users I have a log directory where different logs appear, and an alias to clear it up. I try to define patterns covering all the logs to avoid rm *, which is dangerous and asks for a confirmation. So I define all possible patterns like in an alias, rml: alias rml='rm prefix1.* *.suffix2*' But when some of the patterns match nothing, zsh prints an error about that doesn't do anything. How can I change that behavior to the expected of rm -f ? While I'm on the subject of aliases, looks like zsh aliases are as weak as bash's, so when I have my lr: alias lr='ls -lt | head' which I could not use with a parameter, lr <dir>, I still cannot use a parameter in zsh. In bash, made lr a function -- what the zsh function would look like? And is there a way to do it in an alias, or still not? Alexy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rm nonexisting*; alias with parameters? 2005-08-10 19:18 ` rm nonexisting*; alias with parameters? Deliverable Mail @ 2005-08-10 20:06 ` Peter Stephenson 2005-08-10 20:31 ` Deliverable Mail 0 siblings, 1 reply; 10+ messages in thread From: Peter Stephenson @ 2005-08-10 20:06 UTC (permalink / raw) To: zsh-users Deliverable Mail wrote: > I have a log directory where different logs appear, and an alias to > clear it up. I try to define patterns covering all the logs to avoid > rm *, which is dangerous and asks for a confirmation. So I define all > possible patterns like in an alias, rml: > > alias rml='rm prefix1.* *.suffix2*' > > But when some of the patterns match nothing, zsh prints an error about > that doesn't do anything. How can I change that behavior to the > expected of rm -f ? (Did you miss the -f after the rm? That confused me to begin with but I'll assume so. The shell can't make rm look like rm -f.) I think what you want is that if some patterns *do* match, the ones that don't are silently removed. The neatest way of doing this is "setopt cshnullglob", which uses the csh method: if no patterns match, the shell reports an error, whereas if some do, the others are removed. If you never want the shell error, "setopt nullglob". > While I'm on the subject of aliases, looks like zsh aliases are as > weak as bash's, so when I have my lr: > > alias lr='ls -lt | head' > > which I could not use with a parameter, lr <dir>, I still cannot use a > parameter in zsh. In bash, made lr a function -- what the zsh > function would look like? The same, probably. lr() { ls -lt "$@" | head } > And is there a way to do it in an alias, or still not? No, functions are the right way. This is exactly what they're for. -- Peter Stephenson <pws@pwstephenson.fsnet.co.uk> Work: pws@csr.com Web: http://www.pwstephenson.fsnet.co.uk ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rm nonexisting*; alias with parameters? 2005-08-10 20:06 ` Peter Stephenson @ 2005-08-10 20:31 ` Deliverable Mail 2005-08-10 22:51 ` Mikael Magnusson 0 siblings, 1 reply; 10+ messages in thread From: Deliverable Mail @ 2005-08-10 20:31 UTC (permalink / raw) To: zsh-users Thanks, Peter! (I hear you, Ligesh... will do later :) Worked as described. Making rm -f does not change zsh behavior, of course, as globbing happens before -f can kick in -- so it's a bit confusing that -f doesn't work. Thankfully zsh says zsh: before its globbing error. It's a tricky fault for those who expect rm -f to shut up and do it... Alexy On 8/10/05, Peter Stephenson <pws@pwstephenson.fsnet.co.uk> wrote: > Deliverable Mail wrote: > > I have a log directory where different logs appear, and an alias to > > clear it up. I try to define patterns covering all the logs to avoid > > rm *, which is dangerous and asks for a confirmation. So I define all > > possible patterns like in an alias, rml: > > > > alias rml='rm prefix1.* *.suffix2*' > > > > But when some of the patterns match nothing, zsh prints an error about > > that doesn't do anything. How can I change that behavior to the > > expected of rm -f ? > > (Did you miss the -f after the rm? That confused me to begin with but > I'll assume so. The shell can't make rm look like rm -f.) > > I think what you want is that if some patterns *do* match, the ones that > don't are silently removed. The neatest way of doing this is "setopt > cshnullglob", which uses the csh method: if no patterns match, the > shell reports an error, whereas if some do, the others are removed. If > you never want the shell error, "setopt nullglob". > > > While I'm on the subject of aliases, looks like zsh aliases are as > > weak as bash's, so when I have my lr: > > > > alias lr='ls -lt | head' > > > > which I could not use with a parameter, lr <dir>, I still cannot use a > > parameter in zsh. In bash, made lr a function -- what the zsh > > function would look like? > > The same, probably. > > lr() { > ls -lt "$@" | head > } > > > And is there a way to do it in an alias, or still not? > > No, functions are the right way. This is exactly what they're for. > > -- > Peter Stephenson <pws@pwstephenson.fsnet.co.uk> > Work: pws@csr.com > Web: http://www.pwstephenson.fsnet.co.uk > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rm nonexisting*; alias with parameters? 2005-08-10 20:31 ` Deliverable Mail @ 2005-08-10 22:51 ` Mikael Magnusson 2005-08-11 3:17 ` "splitting prpblem" Meino Christian Cramer 0 siblings, 1 reply; 10+ messages in thread From: Mikael Magnusson @ 2005-08-10 22:51 UTC (permalink / raw) To: zsh-users On 8/10/05, Deliverable Mail <deliverable@gmail.com> wrote: > Thanks, Peter! (I hear you, Ligesh... will do later :) Worked as > described. Making rm -f does not change zsh behavior, of course, as > globbing happens before -f can kick in -- so it's a bit confusing that > -f doesn't work. Thankfully zsh says zsh: before its globbing error. > It's a tricky fault for those who expect rm -f to shut up and do it... > > Alexy You can also add (N) directly after the pattern without the options set and they will silently expand to nothing. ie rm *.txt *.bak(N) will fail if there are no *.txt files but no *.bak files is okay. ^ permalink raw reply [flat|nested] 10+ messages in thread
* "splitting prpblem" 2005-08-10 22:51 ` Mikael Magnusson @ 2005-08-11 3:17 ` Meino Christian Cramer 2005-08-11 8:40 ` Michal Politowski 0 siblings, 1 reply; 10+ messages in thread From: Meino Christian Cramer @ 2005-08-11 3:17 UTC (permalink / raw) To: zsh-users HI, I have a kind of "splitting problem" -- and dont know how to categorize or name it... This is it: I made a script to repack all my *.tar.bz2 files into *.7z file with the high compression packer p7zip. P7zip supports a couple of optimizing options to get most of it in dependance of the used machine (mem etc...). To not to repeat these options every time on a line where p7zip is called I put them into a variable: opt="-t7z -m0=lzma -mx=8 -mfb=64" Now... When calling p7zip with 7z a $opt <file> <arc.7z> p7zip gets confused, because it sees the parameters in $opt as one monlithic block of text. Is there a way to say: "Hey zsh,...if you expand this variable, please let it look like single options..." ? I dont want to call big brothers of big sisters of the utils family like sed, ed, cut, grep or whatever for this tiny job... (...and for what keyword I had to search for in th ezshall docs...I tried things like "$1", "variable expansion", "split" and such and found nothing appropiate...) Keep zshing! Meino ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "splitting prpblem" 2005-08-11 3:17 ` "splitting prpblem" Meino Christian Cramer @ 2005-08-11 8:40 ` Michal Politowski 2005-08-11 17:01 ` Meino Christian Cramer 0 siblings, 1 reply; 10+ messages in thread From: Michal Politowski @ 2005-08-11 8:40 UTC (permalink / raw) To: zsh-users [-- Attachment #1: Type: text/plain, Size: 588 bytes --] On Thu, 11 Aug 2005 05:17:10 +0200, Meino Christian Cramer wrote: [...] > Is there a way to say: "Hey zsh,...if you expand this variable, > please let it look like single options..." ? You want to use an array: opt=(-t7z -m0=lzma -mx=8 -mfb=64) zsh doesn't split scalar parameters on expansion unless the option sh_word_split is set. You can also set it for the duration of a single expansion using ${=opt} but for your own new script you really _do_ want to use arrays :) -- Michał Politowski Talking has been known to lead to communication if practiced carelessly. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: "splitting prpblem" 2005-08-11 8:40 ` Michal Politowski @ 2005-08-11 17:01 ` Meino Christian Cramer 0 siblings, 0 replies; 10+ messages in thread From: Meino Christian Cramer @ 2005-08-11 17:01 UTC (permalink / raw) To: mpol; +Cc: zsh-users From: Michal Politowski <mpol@charybda.icm.edu.pl> Subject: Re: "splitting prpblem" Date: Thu, 11 Aug 2005 10:40:12 +0200 Hi Michael, YES, YES, YEEEEEES!!! I *want* arrays -- right *N*O*W* ! At once ! Where can I get them and what do they cost ? ....and do they keep care of the environment? :) Ok...more seriously... I maked an array from my variable and TADA! it works! Great hint! Thanks a lot, Micheal! Have a nice weekend! Meino > On Thu, 11 Aug 2005 05:17:10 +0200, Meino Christian Cramer wrote: > [...] > > Is there a way to say: "Hey zsh,...if you expand this variable, > > please let it look like single options..." ? > > You want to use an array: > opt=(-t7z -m0=lzma -mx=8 -mfb=64) > > zsh doesn't split scalar parameters on expansion unless the option sh_word_split is set. > You can also set it for the duration of a single expansion using ${=opt} > but for your own new script you really _do_ want to use arrays :) > > -- > Michał Politowski > Talking has been known to lead to communication if practiced carelessly. ^ permalink raw reply [flat|nested] 10+ messages in thread
* serverizing a fat process with named pipes @ 2009-06-16 3:17 ` Alexy Khrabrov 2009-06-16 20:29 ` Peter Stephenson 2009-06-17 0:47 ` Bart Schaefer 0 siblings, 2 replies; 10+ messages in thread From: Alexy Khrabrov @ 2009-06-16 3:17 UTC (permalink / raw) To: zsh-users I have a heavy process, an English parser loading megabytes of models, and then reading stdin, sentence per line, outputting the parsed text to the stdout. How do I properly serverize it -- running in the background with <p1 >p2, those created with mkfifo p1 p2? Looks like unless I wrap that in a kind of a loop, the processes exit at once. First I did this simulation: mkfifo p1 p1 cat <p1 >p2 & cat p2 & echo hi > p1 This does print "hi" and then both backgrounds exit. If I wrap them in while true; do ... done & (& from the original goes outside), the simple one looks running continuously, but the parser takes a while starting up every time, apparently... Cheers, Alexy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: serverizing a fat process with named pipes 2009-06-16 3:17 ` serverizing a fat process with named pipes Alexy Khrabrov @ 2009-06-16 20:29 ` Peter Stephenson 2009-06-17 0:47 ` Bart Schaefer 1 sibling, 0 replies; 10+ messages in thread From: Peter Stephenson @ 2009-06-16 20:29 UTC (permalink / raw) To: zsh-users Alexy Khrabrov wrote: > I have a heavy process, an English parser loading megabytes of models, > and then reading stdin, sentence per line, outputting the parsed text > to the stdout. How do I properly serverize it -- running in the > background with <p1 >p2, those created with mkfifo p1 p2? Looks like > unless I wrap that in a kind of a loop, the processes exit at once. > First I did this simulation: > > mkfifo p1 p1 > cat <p1 >p2 & > cat p2 & > echo hi > p1 > > This does print "hi" and then both backgrounds exit. If I wrap them > in while true; do ... done & (& from the original goes outside), the > simple one looks running continuously, but the parser takes a while > starting up every time, apparently... I think your problem's fairly straightforward: the parser just needs to open the file, read from it, and when it gets EOF on the input, close it again. It can then jump back to trying to open the file again. It's not really a shell problem, it's internal to the parser program. Schematically (not complete code)... for (;;) { FILE *file = fopen(p1); while (fread(file, ....) > 0) { /* parse and output */ } fclose(file); } The programme will block at the fopen() until somebody writes to the other side of the pipe. You can do this sort of thing within the shell, if you need... there's a trick with a variable to get a file descriptor (this *is* working code this time): # initialize here while true; do exec {fd}<p1 # script blocks here until someone writes to p1 # something more exciting goes here... cat <&$fd exec {fd}<&- print Restarting... done That's not quite the same as the loop you originally tried because you've now got control of the file descriptor at the point where the file opens and you hang on to it until you explicitly close it, instead of relying on a process in the middle doing that for you. If you're using a pipe on the output end you'll need to watch out for the server process getting SIGPIPE if the reading process exits. You can simply ignore that ("trap '' PIPE" in the shell) and rely on a write failing to terminate the current iteration and go back and wait to be able to open the output again (but you do either need to handle the SIGPIPE or the failing write). -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: serverizing a fat process with named pipes 2009-06-16 3:17 ` serverizing a fat process with named pipes Alexy Khrabrov 2009-06-16 20:29 ` Peter Stephenson @ 2009-06-17 0:47 ` Bart Schaefer 1 sibling, 0 replies; 10+ messages in thread From: Bart Schaefer @ 2009-06-17 0:47 UTC (permalink / raw) To: Alexy Khrabrov, zsh-users On Jun 15, 11:17pm, Alexy Khrabrov wrote: } } I have a heavy process, an English parser loading megabytes of models, } and then reading stdin, sentence per line, outputting the parsed text } to the stdout. How do I properly serverize it -- running in the } background with <p1 >p2, those created with mkfifo p1 p2? As PWS mentioned in his reply, the nature of FIFOs is that the reader blocks until a writer opens it, and then the reader gets EOF when the writer closes it (and the reader has consumed all the data). If the parser is designed to exit upon EOF, then you can't "serverize" it with FIFOs without repeatedly respawning it. If it does NOT exit on EOF, then something still needs to re-open the FIFO each time, because once the original writer exits the reader will always see EOF on the FIFO. You may be able to work around this as follows: exec {fd}>p1 # Open p1 for writing, but don't write anything cat <p1 >p2 # Replace "cat" with your server process Now other writers can open p1 and send lines to it and even close it again, but "cat" never sees EOF because the shell is holding open $fd. There are still various buffering issues including making sure that someone is appropriately reading from p2, so you might want to look into using inetd or the equivalent to run the process as a service on a socket with a well-known port number instead. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-06-17 0:51 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <deliverable@gmail.com> 2005-08-10 19:18 ` rm nonexisting*; alias with parameters? Deliverable Mail 2005-08-10 20:06 ` Peter Stephenson 2005-08-10 20:31 ` Deliverable Mail 2005-08-10 22:51 ` Mikael Magnusson 2005-08-11 3:17 ` "splitting prpblem" Meino Christian Cramer 2005-08-11 8:40 ` Michal Politowski 2005-08-11 17:01 ` Meino Christian Cramer 2009-06-16 3:17 ` serverizing a fat process with named pipes Alexy Khrabrov 2009-06-16 20:29 ` Peter Stephenson 2009-06-17 0:47 ` 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).