On Tue, Jun 26, 2018 at 07:15:45PM -0700, Elijah Newren wrote:
> Crazy idea: maybe we could defang it a little more thoroughly with
> something like the following (apologies in advance if gmail whitespace
> damages this):
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index
On Tue, Jun 26, 2018 at 05:13:05PM -0400, Eric Sunshine wrote:
> On Tue, Jun 26, 2018 at 5:01 PM Jeff King wrote:
> > On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> > > Some of these dangers can be de-thoothed during the linting phase by
> > > defining do-nothing shell
On Wed, Jun 27, 2018 at 2:27 AM Johannes Sixt wrote:
> Am 27.06.2018 um 04:15 schrieb Elijah Newren:
> > On Tue, Jun 26, 2018 at 2:01 PM, Jeff King wrote:
> >> On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> >>> Some of these dangers can be de-thoothed during the linting phase
Am 27.06.2018 um 04:15 schrieb Elijah Newren:
On Tue, Jun 26, 2018 at 2:01 PM, Jeff King wrote:
On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
Some of these dangers can be de-thoothed during the linting phase by
defining do-nothing shell functions:
cp () { :; }
mv
On Tue, Jun 26, 2018 at 2:01 PM, Jeff King wrote:
> On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
>> Some of these dangers can be de-thoothed during the linting phase by
>> defining do-nothing shell functions:
>>
>> cp () { :; }
>> mv () { :; }
>> ln () { :; }
>>
>>
On Tue, Jun 26, 2018 at 5:33 PM Elijah Newren wrote:
> On Tue, Jun 26, 2018 at 1:22 PM, Jeff King wrote:
> > Another option is to not enable this slightly-more-dangerous linting by
> > default. But that would probably rob it of its usefulness, since it
> > would just fall to some brave soul to
On Tue, Jun 26, 2018 at 1:22 PM, Jeff King wrote:
> On Tue, Jun 26, 2018 at 04:17:08PM -0400, Jeff King wrote:
>
>> I'm not sure if there's a good solution, though. Even if you retained
>> the subshells and instead did a chain-lint inside each subshell, like
>> this:
>
> So obviously that means
On Tue, Jun 26, 2018 at 5:01 PM Jeff King wrote:
> On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> > Some of these dangers can be de-thoothed during the linting phase by
> > defining do-nothing shell functions:
> >
> > cp () { :; }
> > mv () { :; }
> > ln () { :; }
>
Jeff King writes:
> One way this series might be worse in practice is that we tend not to
> change process state too much outside of the subshells.
> ...
> Whereas once you start collapsing subshells into the main logic chain,
> there's a very high chance that the subshell is doing a "cd", since
On Tue, Jun 26, 2018 at 04:46:18PM -0400, Eric Sunshine wrote:
> > I'm not sure if there's a good solution, though. Even if you retained
> > the subshells and instead did a chain-lint inside each subshell, like
> > this:
> >
> > (exit 117) &&
> > one &&
> > (
> > (exit 117) &&
> >
On Tue, Jun 26, 2018 at 4:22 PM Jeff King wrote:
> So obviously that means "I don't think there's a good solution with this
> approach".
>
> That whole final patch simultaneously impresses and nauseates me. Your
> commit message says "no attempt is made at properly parsing shell code",
> but we
On Tue, Jun 26, 2018 at 4:17 PM Jeff King wrote:
> On Tue, Jun 26, 2018 at 03:52:54PM -0400, Eric Sunshine wrote:
> > So, this isn't a new problem introduced by this series, though this
> > series may exacerbate it.
>
> Whereas once you start collapsing subshells into the main logic chain,
>
On Tue, Jun 26, 2018 at 04:17:08PM -0400, Jeff King wrote:
> I'm not sure if there's a good solution, though. Even if you retained
> the subshells and instead did a chain-lint inside each subshell, like
> this:
So obviously that means "I don't think there's a good solution with this
approach".
On Tue, Jun 26, 2018 at 03:52:54PM -0400, Eric Sunshine wrote:
> The existing --chain-lint already suffers the same shortcoming. Older
> (or even new poorly-written) tests, even without subshells, can fall
> victim already:
>
> (exit $sentinel) &&
> mkdir -p a/b/c &&
> cd a/b/c
>
On Tue, Jun 26, 2018 at 3:15 PM Junio C Hamano wrote:
> so, with --chain-lint, we would transform this
>
> mkdir -p a/b/c &&
> (
> cd a/b/c
> rm -fr ../../*
> ) &&
> statement 4
>
> into this sequence
>
> (exit $sentinel) &&
Eric Sunshine writes:
> The --chain-lint option detects broken &&-chains by forcing the test to
> exit early (as the very first step) with a sentinel value. If that
> sentinel is the test's overall exit code, then the &&-chain is intact;
> if not, then the chain is broken. Unfortunately, this
The --chain-lint option detects broken &&-chains by forcing the test to
exit early (as the very first step) with a sentinel value. If that
sentinel is the test's overall exit code, then the &&-chain is intact;
if not, then the chain is broken. Unfortunately, this detection does not
extend to
17 matches
Mail list logo
