Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Feature request: a new warning option
- X-seq: zsh-users 24340
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>
- Subject: Re: Feature request: a new warning option
- Date: Wed, 9 Oct 2019 11:15:39 -0700
- Cc: Zsh Users <zsh-users@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w8AVjWZBQ+kwJ1W8mxiQGYP+W5SJo+/ns4YypwurrO4=; b=nWSy+zP6KmHj5oVuUzNjJ4ZUNq+XT36qRKBkyTFC1iHIW+jORpqrF3QEfZY6LMAqUR Mn7Ac31iIHR5SeJIB0IKXbfPbjE9nUzXTTBpfjfozL+nuU913O7JYmC6mygHichSWARI pr8KlmAhnMHrWpD1nKATeVk93hU4xHhfDsB618/U+m28b3kB+W7ZLU6IClY0AoJWhPJD fQeMlSSHDZUVujSVo/U18PppNf7oky5HCjclZ3isXiFheuNOuu0Hte2Ff1yWuuVvr3aH 98W+2XzuOTpUYcWoq0Blu5vrTNi0S9mp1NFbl2S+CszkXROugf0vNyiZYPCp6UTYPvVZ TDZw==
- In-reply-to: <CAKc7PVDN-GspoiS-iVR5ThdbDVbLWVNJWcZ=TyY0=9ydtPswAw@mail.gmail.com>
- List-help: <mailto:zsh-users-help@zsh.org>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:zsh-users@zsh.org>
- List-unsubscribe: <mailto:zsh-users-unsubscribe@zsh.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <CAKc7PVDN-GspoiS-iVR5ThdbDVbLWVNJWcZ=TyY0=9ydtPswAw@mail.gmail.com>
On Tue, Oct 8, 2019 at 9:03 PM Sebastian Gniazdowski
<sgniazdowski@xxxxxxxxx> wrote:
>
> The warning would be triggered when:
> - a an || would occur after an instruction preceded by &&,
> - the instruction wouldn't be an always-true instruction
To add to what's already been bandied about:
This seems like something better suited for a shell script "lint" type
program, rather than something to emit as a run-time warning from the
shell itself. There's also the question of when this warning would be
emitted; if at execute time, is it really doing anything useful? If
at parse time, the parser has to become aware of even more semantics.
Creation of global variables and references to unset variables can't
really be detected by syntax examination, but all the cases the shell
could successfully warn about in this scheme are, I think, resolvable
by looking at the individual pipelines. If you want a runtime
warning, maybe do something with ${(z)ZSH_DEBUG_CMD} in a TRAPDEBUG
function?
Messages sorted by:
Reverse Date,
Date,
Thread,
Author