rm nonexisting*; alias with parameters?

rm nonexisting*; alias with parameters?

[Deliverable Mail]

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

Re: rm nonexisting*; alias with parameters?

[Peter Stephenson]

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

Re: rm nonexisting*; alias with parameters?

[Deliverable Mail]

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
>

Re: rm nonexisting*; alias with parameters?

[Mikael Magnusson]

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.

"splitting prpblem"

[Meino Christian Cramer]

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

Re: "splitting prpblem"

[Michal Politowski]

[-- 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 --]

Re: "splitting prpblem"

[Meino Christian Cramer]

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.

serverizing a fat process with named pipes

[Alexy Khrabrov]

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

Re: serverizing a fat process with named pipes

[Peter Stephenson]

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/

Re: serverizing a fat process with named pipes

[Bart Schaefer]

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.