recognizing other shebang lines

[Alex Shinn]

Hi,

The attached patch makes the existing shebang

recognition of user-configurable types beyond

the hard-coded perl/python/ruby and shell scripts.

-- 

Alex

[Andy Lester]

Thanks for the patch.  I'm not going to implement it becuase I'm not going to be changing any more in ack 1.x about how filetypes are detected.  ack 2.0 will handle this very flexibly.

xoa

--
Andy Lester => an...@petdance.com => www.petdance.com => AIM:petdance

[Alex Shinn]

On Wed, Apr 25, 2012 at 11:02 PM, Andy Lester <an...@petdance.com> wrote:
>
> On Apr 25, 2012, at 8:27 AM, Alex Shinn wrote:
>
> The attached patch makes the existing shebang
> recognition of user-configurable types beyond
> the hard-coded perl/python/ruby and shell scripts.
>
>
> Thanks for the patch.  I'm not going to implement it becuase I'm not going
> to be changing any more in ack 1.x about how filetypes are detected.  ack
> 2.0 will handle this very flexibly.

It doesn't actually change how they're detected,
it just moves the existing hard-coded pattern to
a variable.

But if ack 2.0 is coming out soon that's great.

--
Alex

[Andy Lester]

On Apr 25, 2012, at 9:16 AM, Alex Shinn wrote:

But if ack 2.0 is coming out soon that's great.

I'm not sure I'd say "soon".  Rob Hoelz and I need to get a list of what's left to do.

But filetype detection will look like this:  https://github.com/petdance/ack2/blob/master/ackrc

[Bill Ricker]

Thanks for the patch.  I'm not going to implement it becuase I'm not going to be changing any more in ack 1.x about how filetypes are detected.  ack 2.0 will handle this very flexibly.

This patch looks quite plausible as a interim measure to keep ack 1.x fresh ( working for new users & usecases ) while we await ack 2 closure -- if only to avoid reinventing the perl6-caused gap in perl5. It's a great idea and we should give a bit more consideration to a fix like this unless  ack2 is truly immanent . 

However I would only vote for it if it is truly conservative, changing no behavior when new flag not used. As presented that is not the case, but it's repairable.

The regression danger I note is it steps over m{/.*/env\s} and/or m{/$pathpattern/} before taking the **next** token, instead of looking for any of a list of tokens **anywhere** in the line.  

I would recode it to build a pattern of the known tokens from the hash indices (once), and look up the match (if any) in the hash, to eliminate the change to behavior on edge cases.

--
Bill
@n1vux bill....@gmail.com

[Andy Lester]

On Apr 25, 2012, at 9:25 PM, Bill Ricker wrote:

However I would only vote for it if it is truly conservative, changing no behavior when new flag not used. As presented that is not the case, but it's repairable.

The regression danger I note is it steps over m{/.*/env\s} and/or m{/$pathpattern/} before taking the **next** token, instead of looking for any of a list of tokens **anywhere** in the line.  

I guess it's hard to tell, because I don't know if the patch was intended as "I scratched my own itch" or "Here's something I think ack ought to do."  Such is the nature of patches thrown over the transom.

If you two can hash something out that isn't destructive, I'll consider it.  I just cringe at adding any more functionality to ack 1.x which is already heavy with bolted-on stuff as it is.

[Andy Lester]

>
> However I would only vote for it if it is truly conservative, changing no behavior when new flag not used. As presented that is not the case, but it's repairable.

Also, maybe we put out an ack with a --nofilter in it.

[Alex Shinn]

On Thursday, April 26, 2012 11:25:24 AM UTC+9, bill....@gmail.com wrote:

Thanks for the patch.  I'm not going to implement it becuase I'm not going to be changing any more in ack 1.x about how filetypes are detected.  ack 2.0 will handle this very flexibly.

This patch looks quite plausible as a interim measure to keep ack 1.x fresh ( working for new users & usecases ) while we await ack 2 closure -- if only to avoid reinventing the perl6-caused gap in perl5. It's a great idea and we should give a bit more consideration to a fix like this unless  ack2 is truly immanent . 

However I would only vote for it if it is truly conservative, changing no behavior when new flag not used. As presented that is not the case, but it's repairable.

The regression danger I note is it steps over m{/.*/env\s} and/or m{/$pathpattern/} before taking the **next** token, instead of looking for any of a list of tokens **anywhere** in the line.  

Yes, I considered the old logic broken because it can

introduce false positives and ambiguities.  With the

new pattern only one language can match.  In 99.9%

of the cases they will be equivalent though.

I'd bet dollars to donuts that if you can find any example

where they differ, then it's an example of a bug in the old

logic that has been fixed :)

I would recode it to build a pattern of the known tokens from the hash indices (once), and look up the match (if any) in the hash, to eliminate the change to behavior on edge cases. 

Sure, if we're not even applying bugfixes to 1.x then it

would be easy enough to do this.

-- 

Alex

--
Bill
@n1vux bill....@gmail.com

[Andy Lester]

On May 8, 2012, at 3:46 AM, Alex Shinn wrote:

Sure, if we're not even applying bugfixes to 1.x then it

would be easy enough to do this.

It's not that we're not applying bug fixes.  I just don't want to add new features to ack 1.x that we'd have to carry over to 2.0.  In the case of the "specify more types via a new command line switch," that's a feature that we'd be adding to 1.x and would be entirely different in 2.0.  So that's both good and bad.

I figure some time in the next few weeks I'll have to put out a new version of ack with various fixes in it.