From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 9D8BA1F462 for ; Sun, 26 May 2019 01:59:22 +0000 (UTC) Received: from localhost ([127.0.0.1]:49583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUiRU-0000rZ-76 for normalperson@yhbt.net; Sat, 25 May 2019 21:59:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUiRP-0000mb-5V for bug-gnulib@gnu.org; Sat, 25 May 2019 21:59:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hUiH5-0004WY-Qp for bug-gnulib@gnu.org; Sat, 25 May 2019 21:48:37 -0400 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]:36158) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hUiH5-0004Vj-Kh for bug-gnulib@gnu.org; Sat, 25 May 2019 21:48:35 -0400 Received: by mail-pf1-x443.google.com with SMTP id u22so228718pfm.3 for ; Sat, 25 May 2019 18:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=T3qQJSbdQdSDz2DU05jb15lQ74B78titoUNSdv5NHTE=; b=PrIt22ok2S550x3Zko65fgUVf3zLjr/wamnoqrEXst3WjRvTJaw6uEEYFFvNWAFZd9 b1bjrAj5TPApnYMEg50dsCl3DMno4PMgw6u3WhE6q2mlLCT7sKF+DTrXxv4ZHCcrIvJ1 8iOn1PfrQ/6Rf4nxKdF0HMZ2VRzHKrPLYyaUUMcgfbDVC/tAJM2e+LYVg3WqDiGPTJmX XN/PnFc3kXQJxJ87HPViTVO19nOSD/pmP8/3MeVmPp3A4CeAy5m8pgyz+yvdsOEraKMJ lEqNVdAyJ7Tq7Q3zTNdju1LA4CDCxPhbpvl4NUoAh7vo06j/Bsou2uH3li+PTTuP5FD1 OpRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=T3qQJSbdQdSDz2DU05jb15lQ74B78titoUNSdv5NHTE=; b=ccfQGQfJdQ21f4TQHPdtRMqlY3dma3WzKrfy2nBVqLZIc6pqGKIeTWVbygQAM2+5Sp ZbJsfnXXXljkFnea50+0ACSpNqupNsmSTxKhgTAi0p7cZm4D6cpKsV4HcvGjaDEzOTzR 777vJZ4f8G3ly9cm/ighxthywEzwuoF/MCe7C3dvtkZZSrjkTmCzaRaqrvjvIGx+BZRA 490+by7A4nRnmsZzzxK8U02qMy5Ej2ujjsr9fzKIGoioz9jmnodGkVDk5tZAxp1H/tUa 0xRatyFtjPfnaG9VoXFDmai1gVxSAvhBG+Kv2wMLzcAtayjdTpTHSUzfHX+UqR7dM0gL nMSA== X-Gm-Message-State: APjAAAVFj5nWP8m+cC0HhflykyOSqEwtj7gznoiTH0jh0VFvpmdHtNgq 22zmMkbztkm07i7/plwyfe6qPTTz2ec= X-Google-Smtp-Source: APXvYqyMFcW3bqmjmQ4+i3xX/SSa+f6nDYkKwzctAPfwncvTc7s9M/3skb/83iYBSSOEF4rKTz6MNg== X-Received: by 2002:aa7:9104:: with SMTP id 4mr94289144pfh.66.1558835313924; Sat, 25 May 2019 18:48:33 -0700 (PDT) Received: from [10.0.2.15] ([125.140.12.15]) by smtp.gmail.com with ESMTPSA id y25sm8433182pfp.182.2019.05.25.18.48.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 May 2019 18:48:33 -0700 (PDT) Message-ID: <5CE9F088.4060504@gmail.com> Date: Sun, 26 May 2019 10:48:56 +0900 From: KO Myung-Hun User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.6esrpre) Gecko/20120715 Firefox/10.0.6esrpre SeaMonkey/2.7.2 MIME-Version: 1.0 To: Bruno Haible Subject: Re: [PATCH] binary-io: do not treat set_binary_mode() on stdin/out/err as an error on OS/2 References: <20190524113138.34458-1-komh@chollian.net> <2065071.Y6UAp6S3dB@omega> <5CE94ED0.1030501@gmail.com> <1603590.9no1ThJX1s@omega> In-Reply-To: <1603590.9no1ThJX1s@omega> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::443 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Bruno Haible wrote: > KO Myung-Hun wrote: >> setmode(O_BINARY) on tty works well instead >> of returning -1 as previous set_binary_mode() does. > > "works well", but isn't this the case which produces staircase-shaped > output? > setmode(O_BINARY) on tty causes the staircase-shaped output. And read CRLF pair not LF from input device. >> In addition, set_binary_mode() breaks the compatibility with >> SET_BINARY() before set_binary_mode(). Because SET_BINARY() does nothing >> on tty. It does not cause any error at all. My patch is compatible with >> SET_BINARY(). > > So you have a problem with the patches by Paul in > > > and then in coreutils > https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=75aababed45d0120d44baa76c5107d0ceb71fc59 > https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=1c27b56095b4a82be7d072baabc09262cb4227e5 > > Paul, what was the problem that motivated these patches? > Was it ? > > There are comments, for example in tr.c, that explain why these programs > want to avoid conversion between LF and CR/LF: > > /* Use binary I/O, since 'tr' is sometimes used to transliterate > non-printable characters, or characters which are stripped away > by text-mode reads (like CR and ^Z). */ > xset_binary_mode (STDIN_FILENO, O_BINARY); > xset_binary_mode (STDOUT_FILENO, O_BINARY); > > Error checking has been added because we want reliable software. > >> the 'abort' is the result of xset_binary_mode() using the result of >> set_binary_mode() which affected by __gl_setmode_check(). >> >> No.many programs of coreutils including tee are using >> xset_binary_mode(). Maybe more programs using xset_binary_mode() of >> gnulib. And they will abort as soon as trying to use xset_binary_mode() >> at startup. > > OK, then maybe the fix is in gnulib. Your justification sounded like only > the 'tee' program was affected. > > You will need to argue what is the desired behaviour, before proposing > a patch. > No problem. > * What is the default mode of stdin/out/err when it is not a tty? > Any files and pipes are opened in text mode by default if a user provide neither a specific mode nor a specific setting. As a result, the default mode of stdin/out/err if not a tty is text mode. However, if stdin/out/err is the non-tty whose mode is binary mode then its mode becomes binary mode. > * Is this default desirable? If not, why not? > Of course. It's default behavior on OS/2. All the OS/2 programs and programmers expect this default. > * What is the default mode of stdin/out/err when it is a tty? > Text mode. > * Is this default desirable? If not, why not? > Desirable. Tty on OS/2 work in text mode. > * When does staircase-shaped output occur? > When stdout which is a tty is in binary mode. So does stderr. > * What is the result of isatty(1) > a) for console output? 1 > b) for pipe output? 0 > c) for regular file output? 0 > > * What is the result of isatty(0) > a) for console input? 1 > b) for pipe input? 0 > c) for regular file input? 0 > > * Can setmode fail, other than when the fd argument is invalid (-> EBADF) or > the mode argument is invalid (-> EINVAL)? > > When you have provided the answers to these questions, maybe we'll get closer. > I hope this help. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v6.0.8 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.os2.kr/