Re: Harmful LESS flags

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

 



David Kastrup <dak@xxxxxxx> writes:

> d9ba@xxxxxxxxxxx writes:
>
>> It would be nice if we could change the flags to either
>>
>>  a) avoid cutting off
>>  b) indicate something has been cut off (<- I prefer this)
>>
>> I assume there are more people with a similar workflow who're still
>> unaware of this feature.
>>
>> I would joke about how 3 letter agencies introduced this flag to
>> backdoor open source projects, but, well..
>
> Most terminals are wider than three letters.

I am having a hard time to decide if you genuinely misread what you
are responding to, or if you are joking.  If the latter, I find the
joke mildly funny in a twisted way ;-)

But the tangent aside...

> Still, it is a total nuisance.  I am constantly doing
>
> -S RET
>
> on my git output.  This should be left alone as an entirely personal
> preference quite unrelated to Git.  There is no point in having Git
> configure a default different from what is used elsewhere.

I almost agree with the general principle of the last sentence, but
with a bit of reservation.  The default value for LESS (i.e. when
the user does not have any) we pass is FRSX, and the Porcelain
output these days is colored by default.  If we don't set a default
at all, the end-user experience for a newbie will be bad, especially
without "R".

Among the other three, F and X are to avoid a short output (e.g "git
show" on a one-liner with a short explanation) from asking for
confirmation to leave the pager and from clearing the screen upon
leaving the pager, and are generally accepted as good things (or at
least, we haven't seen much issue raised after we started passing
the default LESS for those who do not have their own in their
environment).

Use of S is very subjective.  While I personally do appreciate that
we have it by default, I can perfectly well understand why some
people do not want to see it in the default.  The best we can do is
to arrange so that people from one of the camps have their favorite
out of the box and those from the other camp need to tell Git that
they want to (or do not want to) fold long lines.

Traditionally, because the tool grew in a context of being used in a
project whose participants are at least not malicious, always having
to be on the lookout for fear of middle-of-line tabs hiding bad
contents near the right edges of lines has never been an issue.  If
somebody brought up a potential issue of such mode of attack back
then, Linus may have chosen the default differently.  I may have
myself chosen not to have S, if I were the maintainer when the LESS
default was originally introduced, and had I been made aware of this
issue.

I am not opposed to changing the default in the longer term, as long
as we have a solid transition plan to ensure that it won't disrupt
and/or upset existing users too much.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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]