Martin Natano wrote:
> I agree with Ingo, ls(1) shouldn't generate unsafe output. Regardless
> of whether the output is to a terminal or some other file.
While POSIX is not holy law, doing what you suggest would probably be a
violation. See the description of the -q option:
Ingo Schwarze wrote:
> The old ls(1) also weeded out non-printable bytes, in particular
> control codes.
The old ls only had this behavior for terminals however. Redirecting to a file
or pipe would always output the original bytes.
On 2016/01/17 14:29, Ted Unangst wrote:
> Ingo Schwarze wrote:
> > The old ls(1) also weeded out non-printable bytes, in particular
> > control codes.
>
> The old ls only had this behavior for terminals however. Redirecting to a file
> or pipe would always output the original bytes.
I've used
I agree with Ingo, ls(1) shouldn't generate unsafe output. Regardless
of whether the output is to a terminal or some other file.
cheers,
natano
ijn van Duren <openbsd+t...@list.imperialat.at>, tech@openbsd.org
Subject: Re: [patch] ls + utf-8 support
Hi,
Stuart Henderson wrote on Sun, Jan 17, 2016 at 07:46:23PM +:
> On 2016/01/17 14:29, Ted Unangst wrote:
>> Ingo Schwarze wrote:
>>> The old ls(1) also weeded out non-
Hi,
Stuart Henderson wrote on Sun, Jan 17, 2016 at 07:46:23PM +:
> On 2016/01/17 14:29, Ted Unangst wrote:
>> Ingo Schwarze wrote:
>>> The old ls(1) also weeded out non-printable bytes, in particular
>>> control codes.
>> The old ls only had this behavior for terminals however.
>>
Hi Martijn,
Martijn van Duren wrote on Sun, Jan 17, 2016 at 12:58:38PM +0100:
> I've come across a fair amount of malformed file names by all sorts
> of causes. Be it malware or just human error. When such a malformed
> character is in an inconvenient place and can't be auto-completed
> I
