[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: possible bug in GNU csplit

From: Bob Proulx
Subject: Re: possible bug in GNU csplit
Date: Mon, 7 Jul 2003 22:17:35 -0600
User-agent: Mutt/1.3.28i

Jared Hansen wrote:
> The file testfile.txt is attached; it's the file I was working with when 
> I encountered the odd behavior.   Here's what happened:
> On my windows machine, I can run:
> ---
> csplit testfile.txt '/###/' {*}

What does "{*}" do under MS-Windows?  I only rarely interact with
MS-Windows and don't have a clue what that would do.

Using zsh or other Bourne/POSIX compatible shell you will need to
quote the '*' to protect it from expansion.

> and depending on whether my shell is zsh or cmd.exe, I get, respectively:
> ---
> zsh: no matches found.  {*}
>    or
> csplit: '/###/' invalid pattern

No matches found sounds like something that zsh does when it has a
file glob (glob is '*' which matches a glob of characters) which does
not match.  In this case you would match a filename like {foo} or
{bar} or some other pattern with curly braces on the ends.  You need
to quote that argument to prevent that expansion attempt.

> I am new to the csplit utility, but I'd been over the man page about 5 
> times, and I checked for other examples, and was pretty sure I was doing 
> it correctly.  Trying it out on my Debian box, I got the behavior I 
> expected (a list of offsets where the file had been split, and a bunch 
> of new files were created).  I was able to reproduce this behavior 
> several times.  The windows machine is on Win2k, although I doubt it 
> makes any difference in this case....  I am interested to know why the 
> error message reported to zsh is different from the one reported to 
> cmd.exe, but that's more idle curiosity than anything...

Unfortunately that is probably the only one of the two I can guess at
answering.  I don't use csplit very much myself either.  zsh is trying
to expand the '*' into a filename match.  But I am guessing that
cmd.exe, whatever that is, does not do the expansion or does something
entirely different with it.

> I am not sure whether this is actually a bug, or whether there's a 
> difference in the win32 port of the utility that isn't documented (which 
> would make it a bug in the documentation, I guess), but I thought that I 
> would report it because it was easy enough to reproduce, and really had 
> me baffled until I thought to see whether the problem was with the port 
> of the utility instead of with the syntax I was using.

Hmm...  You might want to look at the Cygwin site and mailing list.
Most of us over on this mailing list do not use Cygwin ourselves and
so we rely upon the Cygwin folks for issues related to the port.  (Of
course if you can recreate problem on Debian GNU/Linux then we are all
set to handle it here! :-)

  Cygwin Home Page


  Cygwin FAQ.


  Cygwin Bug Report Guidelines.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]