Path: csiph.com!news.mixmin.net!news.unit0.net!takemy.news.telefonica.de!telefonica.de!newsfeed.esat.net!171.64.64.130.MISMATCH!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: Reading from a file by using its FD returns its contents only once Date: Mon, 31 Dec 2018 14:21:30 -0500 Organization: ITS, Case Western Reserve University Lines: 87 Approved: bug-bash@gnu.org Message-ID: References: Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1546284100 5457 208.118.235.17 (31 Dec 2018 19:21:40 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: mike b , bug-bash@gnu.org Envelope-to: bug-bash@gnu.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:cc:subject:to:references:from:openpgp :autocrypt:organization:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=gh0qQmcBrxh7yy9WUAKLjmumjDVaoUizjATvpFH/wmY=; b=TZQmZygBEx3DKLUM+Pn6IqHWS5XjBMZPtXtm05kIpOkfm3xlL/Mq4u2DjODj/vKhPi bNoKXrcmBiuVw+LOyY9YsvO9Mu4b4U6pEC6+NblGjd76rxsuDlY79fg7vkUrt83OKVgL rLlp2AqX0BotZRvN3mH3E3rYbK8T45grZValxcVRQG8Uj56pN9rOorS2cbq1RA818BdT W5QGKFawgaOp2eGtwHtED4hSwtyKMcwHK70SFUlbbHUIp0PXsylomyAh+j+mLxgHumq6 f0lAJsSxQlZCTeA3+dZx+QUFuSYdIH2SVL+ASt32M60bmbcZFTlZum18JnbeVQFYj8Hg i/EA== X-Gm-Message-State: AA+aEWamx/UucpgsVgGAkGj7XwRF8ZAk/QrqnlHScDGnYMQmO++mAzAo JRxWXAkdMWNJarTt8lpOIFLydGm7YXTF7Rs1kIHVLG4XTBsIKz/oIpZ3cHR60e7e3sInXSFQI3X wNQyR3sT4uko= X-Received: by 2002:a81:9858:: with SMTP id p85mr37958761ywg.202.1546284092856; Mon, 31 Dec 2018 11:21:32 -0800 (PST) X-Google-Smtp-Source: AFSGD/XuhH1vEUejrsd9CcggXMzug07Iu15MzeLyrrPpc+vdMbsVrYXkStDiIgfOAU/pjAJCg2ZsTA== X-Received: by 2002:a81:9858:: with SMTP id p85mr37958752ywg.202.1546284092638; Mon, 31 Dec 2018 11:21:32 -0800 (PST) Openpgp: preference=signencrypt Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= mQGiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJLQwQ2hldCBSYW1l eSAoQ2FzZSBzdGFuZGFyZCkgPGNoZXQucmFtZXlAY2FzZS5lZHU+iF8EExECAB8FAkPi19EC GwMHCwkIBwMCAQMVAgMDFgIBAh4BAheAAAoJELtYafBk6nSrelkAn31Gsuib7GcCZHbv5L5t VKYR9LklAJ4hzUHKA49Z0QXR+qCb80osIcmPSbkBDQRBDrBvEAQAkK6TAOKBEM+EC4j6V/7o /riVZqcgU5cid2qG9TXdwNtD9a3kvA/ObZBO93sX59wc6Bnwo4VJxsOmMlpGrAjJsxNwg3QH akEtf8LXRbVpj5xStdmBdQZUhIQyalo/2/TZq5OijtddUQcL5cs70hTv/FpT3wUvr2Xr8rjF 41IFEz8AAwcD/A0CZEGlzIrT5WCBnl6xBog/8vKiUCbarByat3d1mL6DbizvKNXQRTC9E/vE dENAWCQCjr75Bu55xT8n3SXGtWdDC5xmZ/P3OBYORP8yl8H8I1FIosWOFirbIeYdZPq8SPD1 HL+EXo9zSiHVrrZRJ19ooCKKbSdXHFCY+aJG+0KZiEkEGBECAAkFAkEOsG8CGwwACgkQu1hp 8GTqdKvjcACfZlkVCDwaz/NTO9cy3t69oWpVPNwAnRwe0qk/WL/gfhH346xh5B3HFbFN User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 In-Reply-To: Content-Language: en-US X-Junkmail-Status: score=7/90, host=mpv3-2015.case.edu X-Junkmail-PrAS-Raw: score=7/90, refid=2.7.2:2018.12.31.184516:17:7.944, ip=, rules=__YOUTUBE_RCVD, __X_GOOGLE_DKIM_SIGNATURE, __HAS_REPLYTO, __HAS_CC_HDR, __SUBJ_REPLY, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __TO_MALFORMED_2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __REFERENCES, __HAS_FROM, FROM_EDU_TLD, __HAS_MSGID, __SANE_MSGID, DATE_TZ_NA, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __FROM_DOMAIN_IN_ANY_CC1, __FROM_DOMAIN_IN_ANY_CC2, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __URI_WITH_PATH, __URI_NO_WWW, __CP_URI_IN_BODY, __FRAUD_MONEY_CURRENCY_DOLLAR, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, __FRAUD_MONEY_CURRENCY, BODY_SIZE_5000_LESS, [TRUNCATED], so=2010-03-03 19:42:08, dmn=2016-08-03-0138 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 129.22.103.194 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:15022 On 12/30/18 8:36 PM, mike b wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > I am not quite sure if this is a bug, but here's what I find as a bit odd > behavior: It's not odd. > # modprobe zram num_devices=0 > # exec {add} # read -r id <&"$add"; echo "$id" > 0 > # read -r id <&"$add"; echo "$id" # <- $id ends up empty, no data is read > > # read -r id 1 > # read -r id 2 > # readlink -f "/proc/$$/fd/$add" > /sys/class/zram-control/hot_add > > The above sysfs interface is used for creating a zram device by performing > a read on the hot_add file. The value that should be returned is the id of > the newly created device. In first instance file is opened by dynamically > allocating the fd to use "$add" (the fd) across reads instead of > referencing the file directly. But from the above example you can see that > $id is assigned an actual value only on first read. On every next one, $id > would become empty - when using $add, that is. However, when file is read > in a standard way, by using it directly, everything works as it should. The difference between the two methods is that the fd method keeps an fd ($add) open to the file and does not rewind it between reads. If the file returns EOF on the second and subsequent reads from the open file, you'll get the behavior you observe. The `standard' way opens the file, which has the side effect of setting the file pointer to 0, each time. I assume the special file has some sort of behavior triggered by `open', and that's how the designers intended it to be used. > The above is just an example. Doing reads on any other regular file like > this yields same behavior: > # echo bla >./t > # exec 10<./t > # read -r <&10 > # echo $REPLY > bla > # read -r <&10 > # echo $REPLY You're reading to EOF on the first read and getting EOF on the second (this is basically how `while read' loops work). > > # > Playing with something like: > # zram=/sys/class/zram/control/hot_add > # c=0; while ((++c <= 3)); do read -r; echo "${REPLY:-NULL}"; done <"$zram" > 0 > NULL > NULL Same. > # > also gets same results. In contrast to: > # c=0; while (( ++c <= 3 )); do read -r; echo "out: ${REPLY:-NULL}"; done > foo > out: foo > foo > out: foo > foo > out: foo > # > which keeps reading from default stdin (terminal in this case) without any > hiccups (as expected). The terminal doesn't really have an EOF. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/