Re: [PATCH v2 01/10] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells

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

 



On Tue, Jul 31, 2018 at 02:55:51PM -0400, Eric Sunshine wrote:

> > I hesitate to make any suggestion here, as I think we may have passed
> > a point of useful cost/benefit in sinking more time into this script.
> > But...is switching to awk or perl an option? Our test suite already
> > depends on having a vanilla perl, so I don't think it would be a new
> > dependency. And it would give you actual data structures.
> 
> It would, and I did consider it, however, I was very concerned about
> startup cost (launch time) with heavyweight perl considering that it
> would have to be run for _every_ test. With 13000+ tests, that cost
> was a very real concern, especially for Windows users, but even for
> MacOS users (such as myself, for which the full test suite already
> takes probably close to 30 minutes to run, even on a ram drive). So, I
> wanted something very lightweight (and deliberately used that word in
> the commit message), and 'sed' seemed the lightest-weight of the
> bunch.

Both perl and sed seem about the same on my system (sometimes one is
faster than the other, and sometimes vice versa). However, I expect for
Windows the problem is not how big the child executable is, but running
a child process at all. I might be wrong, though.

> 'awk' might be about as lightweight as 'sed', and it may even be
> possible to coerce it into handling the task (since the linter's job
> is primarily just a bunch of regex matching with very little
> "manipulating"). v1 of the linter was somewhat simpler and didn't deal
> with these more complex cases, such as nested here-docs. v1 also did
> rather more "manipulating" of the script since the result was meant to
> be run by the shell. When it came time to implement v2, which detects
> broken &&-chains itself by textual inspection, most of the
> functionality (coming from v1) was already implemented in 'sed', so
> 'awk' never really came up as a candidate since rewriting the script
> from scratch in 'awk' didn't seem like a good idea. (And, at the time
> v2 was started, I didn't know that these more complex cases would
> arise.) So, 'awk' might be a viable alternative, and perhaps I'll take
> a stab at it for fun at some point (or not), but I don't think there's
> a pressing need right now.

Yeah, I agree with that.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux