Bug #130304 for Perl-Tidy: standard error output should include filename

Thu Aug 15 07:50:02 2019 ville.skytta [...] iki.fi - Ticket created

Subject:	standard error output should include filename
Date:	Thu, 15 Aug 2019 14:49:41 +0300
To:	bug-Perl-Tidy [...] rt.cpan.org
From:	Ville Skyttä <ville.skytta [...] iki.fi>

When perltidy is run against a bunch of files, for example in a pre-commit setup and/or in CI, it is often useful to use --standard-error-output. However, perltidy's warning messages do not contain any information which file they are related to, they might just be like: 219: operator in print statement not recommended It can be pretty difficult to find out which file this warning originated from. Prepending the filename to the output like: filename:linenumber: message ...would be much more useful, especially when outputting to stdout/stderr instead of an .ERR file. (I wouldn't personally mind them there either.) And from such a format editors might be able to provide links to jump to source code etc.

Thu Aug 15 15:05:10 2019 perltidy [...] users.sourceforge.net - Correspondence added

On Thu Aug 15 07:50:02 2019, ville.skytta@iki.fi wrote: Show quoted text

> When perltidy is run against a bunch of files, for example in a > pre-commit setup and/or in CI, it is often useful to use > --standard-error-output. However, perltidy's warning messages do not > contain any information which file they are related to, they might > just be like: > > 219: operator in print statement not recommended > > It can be pretty difficult to find out which file this warning > originated from. Prepending the filename to the output like: > > filename:linenumber: message > > ...would be much more useful, especially when outputting to > stdout/stderr instead of an .ERR file. (I wouldn't personally mind > them there either.) And from such a format editors might be able to > provide links to jump to source code etc.

This is a good idea, but I wonder if it would be simpler to just output a single line with the current file name (if it has errors) with something distinctive like FILE:'file1.pl' ..error messages for this file.. FILE:'file2.pl' ..error messages for file2.. Possible advantages: -There are many types of messages besides those with line numbers, so this is cleaner. -This wouldn't interfere with any current file parsing -This conserves line width when file names are long -This FILE line could always go out to stderr, regardless of its ultimate destination

Thu Aug 15 15:05:10 2019 The RT System itself - Status changed from 'new' to 'open'

Thu Aug 15 15:30:05 2019 ville.skytta [...] iki.fi - Correspondence added

Subject:	Re: [rt.cpan.org #130304] standard error output should include filename
Date:	Thu, 15 Aug 2019 22:29:35 +0300
To:	bug-Perl-Tidy [...] rt.cpan.org
From:	Ville Skyttä <ville.skytta [...] iki.fi>

Thanks for looking into this. I wonder if there's a valid scenario in which output from multiple perltidy processes could end up intermixed, thus making a multiline messaging format like the above one perhaps more susceptible to problems than a single line per message. For example the pre-commit package mentioned in another ticket runs several processes in parallel by default. On the other hand, such writes might not be atomic even for a single line, so maybe this is not something to worry about. (Well, or maybe try making them as close as atomic as possible if that's some way sanely doable.) Anyway, if a line number is not available, I'd personally probably just leave it out but stick with the oneliners, so the lines would become just filename: error message But having the info out there in _some_ form is the essence here, no that strong opinions on the formatting details.

Sat Aug 17 14:09:18 2019 perltidy [...] users.sourceforge.net - Correspondence added

On Thu Aug 15 15:30:05 2019, ville.skytta@iki.fi wrote: Show quoted text

> Thanks for looking into this. > > I wonder if there's a valid scenario in which output from multiple > perltidy processes could end up intermixed, thus making a multiline > messaging format like the above one perhaps more susceptible to > problems than a single line per message. For example the pre-commit > package mentioned in another ticket runs several processes in parallel > by default. On the other hand, such writes might not be atomic even > for a single line, so maybe this is not something to worry about. > (Well, or maybe try making them as close as atomic as possible if > that's some way sanely doable.) > > Anyway, if a line number is not available, I'd personally probably > just leave it out but stick with the oneliners, so the lines would > become just > filename: error message > But having the info out there in _some_ form is the essence here, no > that strong opinions on the formatting details.

I agree that having the filename on each line is desirable and I have written a patch that seems to be working well. It will be in the next release. Steve

Sun Aug 18 04:07:21 2019 ville.skytta [...] iki.fi - Correspondence added

Subject:	Re: [rt.cpan.org #130304] standard error output should include filename
Date:	Sun, 18 Aug 2019 11:06:53 +0300
To:	bug-Perl-Tidy [...] rt.cpan.org
From:	Ville Skyttä <ville.skytta [...] iki.fi>

Thanks! Looking at the commit message, some other tools that report similar errors use for example "<stdin>" as filename for standard input. No real problem with just "perltidy:" here, just mentioning this in case you find it a good idea worth adopting.

Sun Aug 18 09:15:15 2019 s7078hancock [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #130304] standard error output should include filename
Date:	Sun, 18 Aug 2019 06:14:46 -0700
To:	bug-Perl-Tidy [...] rt.cpan.org
From:	Steven Hancock <s7078hancock [...] gmail.com>

It's funny you mention that because I was just in the process of making that change. On Sun, Aug 18, 2019 at 1:07 AM ville.skytta@iki.fi via RT < bug-Perl-Tidy@rt.cpan.org> wrote: Show quoted text

> Queue: Perl-Tidy > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=130304 > > > Thanks! > > Looking at the commit message, some other tools that report similar > errors use for example "<stdin>" as filename for standard input. No > real problem with just "perltidy:" here, just mentioning this in case > you find it a good idea worth adopting. > >

Sat Sep 14 20:30:22 2019 perltidy [...] users.sourceforge.net - Correspondence added

Version 20190915 has this update

Sat Sep 14 20:30:23 2019 perltidy [...] users.sourceforge.net - Status changed from 'open' to 'resolved'