empty pipes

empty pipes

[Ray Andrews]

Is there some way of asking zsh to ignore an empty pipe?  I attempted 
something like this:

print $string | $filter | $another_filter

... and it won't accept the filter being empty but sometimes I want the 
filtering and sometimes not.  There's other ways to do it of course, but 
the above would be cool it it could be made to work.

Re: empty pipes

[Bart Schaefer]

On Sun, Dec 11, 2022 at 7:17 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Is there some way of asking zsh to ignore an empty pipe?

No.

> print $string | $filter | $another_filter
>
> ... and it won't accept the filter being empty

That's why you have e.g. ${filter:-cat}.

Re: empty pipes

[Ray Andrews]

On 2022-12-11 19:40, Bart Schaefer wrote:
>
> That's why you have e.g. ${filter:-cat}.
>
Works.  Interesting that property 'cat' has of doing nothing there but 
politely moving the stream forward.  I don't recall ever using that 
construction before but the sweet thing is that I now know where to look 
for information about it.  Such wealth in the parameter expansions.  BTW 
thanks to our previous discussions concerning 'tree' I already know that 
my $filter must be an array quoted so as to present the correct 
invisible structure.  Easy once you understand the issue.

BTW, do we have hard spaces? In certain columnizing situations an empty 
field is a problem so a field of hard spaces would hold the position 
while showing nothing.

Re: empty pipes

[Bart Schaefer]

On Mon, Dec 12, 2022 at 6:02 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> BTW, do we have hard spaces?

That's up to the terminal and the context.  Zsh normally doesn't
output special characters like non-breaking spaces but since you refer
to ...

> certain columnizing situations

... I would presume you're controlling the output, so you could place
$'\u00a0' wherever you need it.

Most terminals are going to wrap at the right margin even for
non-breaking spaces, so unless you're using a proportional font for
some reason, ASCII spaces are likely just as good.

Are there zsh error message explanation

[Xiao Ling XL Chen]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

I failed to get zsh error message explanation in user guide and community, is there any way to get more zsh error message explanation? ie. “./Src/exec.c:3277: zerr("no match");” it is too short to help users to understand the root cause of the error and what action they should take.


Take care, stay strong, and stay safe.

Best regards,
Sunny (Xiao Ling Chen, 陈小玲)

z/OS USS SU&DBX Development and L3
IBM China Systems & Technology Lab (CSTL)
Tel:    86-010-82452454
E-mail: chenxlxl@cn.ibm.com<mailto:chenxlxl@cn.ibm.com>
--



[-- Attachment #2: Type: text/html, Size: 3129 bytes --]

Re: Are there zsh error message explanation

[Daniel Shahaf]

Xiao Ling XL Chen wrote on Wed, Dec 14, 2022 at 13:05:54 +0000:
> I failed to get zsh error message explanation in user guide and community, is there any way to get more zsh error message explanation? ie. “./Src/exec.c:3277: zerr("no match");” it is too short to help users to understand the root cause of the error and what action they should take.

First, don't start a new thread by clicking "Reply" on some post and
then deleting the subject line and message body.  That breaks threading.

To answer your question, that particular error message means the
CSH_NULL_GLOB option has fired.  The message could be improved, yes.
Any volunteers?

Re: Are there zsh error message explanation

[Bart Schaefer]

On Thu, Dec 15, 2022 at 1:18 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> To answer your question, that particular error message means the
> CSH_NULL_GLOB option has fired.  The message could be improved, yes.

We've had this discussion before and decided to stay with the error
messages that all shells with similar features have in common, even if
they may be terse.

Re: Are there zsh error message explanation

[Ray Andrews]

On 2022-12-15 19:28, Bart Schaefer wrote:
>
> We've had this discussion before and decided to stay with the error
> messages that all shells with similar features have in common, even if
> they may be terse.

Not that there's any hope of this, but one of my bright ideas was to 
have every error message in the universe include an ID code, which could 
be looked up in some reference where they would be elaborated on:

#953: improper type for array assignment

... you look up #953 in the Great Book of Errors and see:

#953: zsh has detected that whereas you have declared (yes I know wrong 
word but ...) an array of a certain type, you are attempting to assign 
something to that array that is incompatible with it's type.  For 
example,  .... (and so on).  So whereas the messages might remain terse, 
voluminous information would still be easy to access.

My own error messages optionally return their function and line number, 
it can be quite handy.

Re: Are there zsh error message explanation

[Bart Schaefer]

On Thu, Dec 15, 2022 at 7:53 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Not that there's any hope of this, but one of my bright ideas was to
> have every error message in the universe include an ID code

Even if the error messages printed by the shell don't change, a
volunteer to write a yodl page listing them all and cross-referencing
them to other manual sections would not be turned away.

Re: Are there zsh error message explanation

[Ray Andrews]

On 2022-12-15 20:07, Bart Schaefer wrote:
> On Thu, Dec 15, 2022 at 7:53 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Not that there's any hope of this, but one of my bright ideas was to
>> have every error message in the universe include an ID code
> Even if the error messages printed by the shell don't change, a
> volunteer to write a yodl page listing them all and cross-referencing
> them to other manual sections would not be turned away.

I still dream of actually doing something useful one day to earn my keep.




>

Re: Are there zsh error message explanation

[Daniel Shahaf]

Bart Schaefer wrote on Thu, Dec 15, 2022 at 19:28:15 -0800:
> On Thu, Dec 15, 2022 at 1:18 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > To answer your question, that particular error message means the
> > CSH_NULL_GLOB option has fired.  The message could be improved, yes.
> 
> We've had this discussion before and decided to stay with the error
> messages that all shells with similar features have in common, even if
> they may be terse.

Pointer to the previous discussion, please?  I grepped and haven't
found anything, and from your (terse…) summary I don't understand why
we prefer compatibility with other shells over user-friendliness,
especially considering that:

- "Optimize for the common case."  Most people who will see an error
  message are not newly converted from other shells.  For instance,
  changing zsh's error message to "bad command or file name" wouldn't
  make things perceptibly easier for cmd.exe convertees.

- It's not an either/or case.  If the current error message says "foo"
  then we can change it to say "foo: some elaboration about foo".  The
  leading "foo" part would still be there.

- The error message is unclear and should be improved.  Compatibility
  doesn't mean we can't ever change the error message; it just limits
  what changes we will consider.

Cheers,

Daniel

Re: Are there zsh error message explanation

[Ray Andrews]

On 2022-12-16 04:47, Daniel Shahaf wrote:
>
> - The error message is unclear and should be improved.  Compatibility
>    doesn't mean we can't ever change the error message; it just limits
>    what changes we will consider.
>
Well said.  I can't remember it exactly but I recall complaining about 
one message that was not only terse it was positively misleading. I 
vaguely recall it being something to the effect that zsh couldn't find 
something, whereas in fact she could find it alright but just didn't 
like it.  Nope, compatibility with inferior traditions is not a virtue.  
The other shells are either extinct or moribund.  Zsh owns the field and 
she should start making the rules, not following them.  Who cares if 
something is compatible with rc shell anymore?  They say that csh was a 
monstrosity from the getgo and is best forgotten, not conformed with.  
Let's have better messages -- or ID's so that you can look up the long 
version.

Re: empty pipes

[Ellenor Bjornsdottir]

In the alternative, you can build the string used to execute the 
pipeline piecemeal?

On 12/13/22 02:04, Bart Schaefer wrote:
> On Mon, Dec 12, 2022 at 6:02 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> BTW, do we have hard spaces?
> That's up to the terminal and the context.  Zsh normally doesn't
> output special characters like non-breaking spaces but since you refer
> to ...
>
>> certain columnizing situations
> ... I would presume you're controlling the output, so you could place
> $'\u00a0' wherever you need it.
>
> Most terminals are going to wrap at the right margin even for
> non-breaking spaces, so unless you're using a proportional font for
> some reason, ASCII spaces are likely just as good.
>
-- 
Ellenor Agnes Bjornsdottir (she)
sysadmin umbrellix.net
jabber: ellenor ~on~ umbrellix.net