Re: lseek on tty
Date:Tue, 19 Sep 2023 17:51:56 +0200 From:Rhialto Message-ID: | It may also be that the 2018 edition is not the latest, It is the latest that has been published, everything later is just a draft for what will become (next year sometime, probably) Issue 8. | or that there is some addition "Additional APIs for the Base | Specifications Issue 8, Part 1 & 2". Not sure what the dates are on those, but there's nothing new since about the end of June or something (and too late now to add anything new).Not relevant to the current discussion, as lseek isn't new (changes to existing interfaces aren't usually considered as an additional API - that would be a whole new function, or command, just perhaps a major new option added to one of those). kre
Re: lseek on tty
On Mon 18 Sep 2023 at 18:22:34 -0400, Mouse wrote: > As for standards...which standard? The only one I know of which I > think is likely to say anything about this is POSIX, which as far as I > can recall I don't have a copy of. This should help: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ although when I recently tried to get to there from the start page https://opengroup.org, I didn't manage to find it. I only found options to buy documents. It may also be that the 2018 edition is not the latest, or that there is some addition "Additional APIs for the Base Specifications Issue 8, Part 1 & 2". -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: lseek on tty
Date:Mon, 18 Sep 2023 17:59:38 -0400 From:Jan Schaumann Message-ID: | Wouldn't it be more helpful to the user to have | lseek(2) return -1 here? Not really, this is ancient practice, from the very very early days. | Since it's undefined, which is quite likely only because linux gratuitously decided to break this. Removing backwards compat for this would be the wrong thing to do. (As far as I'm aware, only pipes ever give errors on what would otherwise be a valid seek operation). kre
Re: lseek on tty
On Mon, Sep 18, 2023 at 04:20:28PM -0400, Jan Schaumann wrote: > I'm trying to think of why seeking on a terminal > would make sense. Anybody have an idea? Somebody at a historical GUUG or EUUUG* meeting told the story of a student at his work Uni who had did the mainframe equivalent of lseek(tapepunch, 0, SEEK_SET) (or, in PASCAL dialect, rewrite(tapepunch)). He described the logical operation tried it as rewinding the paper tape and glueing all the small paper disclets back into the holes. (The machine in question froze hard, whenever he tried it, and the responsible person would never have been caught, hadn't he started to bring in friends and relatives to show them how he could make the mainframe operators scurry around in panic by submitting about 5 punched cards.) -is *) I'm slightly too young to have been there, but read the report a few years later in an old GUUG publication. -- Ignatios Souvatzis, Chief IPv6 enabler RFC 6540 Gemeinsame Systemgruppe b-it + Informatik Tel. +49 228 73-60701 g...@cs.uni-bonn.de smime.p7s Description: S/MIME cryptographic signature
Re: lseek on tty
>>> On NetBSD and macOS, lseek(2) on a tty succeeds: >>> if (lseek(STDIN_FILENO, 0, SEEK_CUR) == -1 ) >> Some devices are incapable of seeking. The value of the >> pointer associated with such a device is undefined. >> So I'm guessing it depends on whether you think of adding something >> to an undefined value makes sense. > Kinda feel this makes a successful return value of lseek(2) quite > unreliable: it could either mean that lseek(2) was successful, and > has updated the offset, or it could mean ":shrug: can't seek, you are > wherever you were before calling me". Well, I suspect that, as =?utf-8?B?0L3QsNCx?= suggested upthread, it _did_ update the offset, but the offset doesn't affect anything on a tty. I ran into a related case back in the day on SunOS, with 32-bit offsets: after writing 2G of data to a tape, it would abruptly start failing, apparently because the offset wrapped around and went negative. Adding an explicit lseek(,0,SEEK_SET) every once in a while cured it. Because tapes, like ttys, don't do anything with the offset, all this did was shut off the spurious error. > Wouldn't it be more helpful to the user to have lseek(2) return -1 > here? Would it? I'm not sure. What user would be helped by getting an error (and which error?) instead of success? You say Linux fails, but I don't see compatibility with Linux as enough of a Good Thing for that alone to be grounds for changing, especially since you say macOS also accepts it and thus reasonably portable code has to be prepared for either behaviour. > Since it's undefined, doing so is equally as valid (as far as the > standard is concerned). The value of the offset is undefined. That is not to say that erroring versus not erroring is undefined. (It may be, but your unqualified "it's undefined" appears to be referring back to my quote, in which case it's talking about just "the value of the [seek] pointer", not whether or not lseek itself fails.) As for standards...which standard? The only one I know of which I think is likely to say anything about this is POSIX, which as far as I can recall I don't have a copy of. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: lseek on tty
Mouse wrote: > > On NetBSD and macOS, lseek(2) on a tty succeeds: > > > if (lseek(STDIN_FILENO, 0, SEEK_CUR) == -1 ) > > > On Linux, this fails. > > > I'm trying to think of why seeking on a terminal would make sense. > > Anybody have an idea? > > Quoting from lseek(2) on a handy machine: > > Some devices are incapable of seeking. The value of the > pointer associated with such a device is undefined. > > So I'm guessing it depends on whether you think of adding something to > an undefined value makes sense. To me, it does; the resulting value is > undefined, but the seek pointer is undefined anyway. Kinda feel this makes a successful return value of lseek(2) quite unreliable: it could either mean that lseek(2) was successful, and has updated the offset, or it could mean ":shrug: can't seek, you are wherever you were before calling me". Wouldn't it be more helpful to the user to have lseek(2) return -1 here? Since it's undefined, doing so is equally as valid (as far as the standard is concerned). -Jan
Re: lseek on tty
On Mon, Sep 18, 2023 at 04:20:28PM -0400, Jan Schaumann wrote: > On NetBSD and macOS, lseek(2) on a tty succeeds: > On Linux, this fails. > > I'm trying to think of why seeking on a terminal > would make sense. Anybody have an idea? This is historical UNIX behaviour ‒ the file offset is modified, but it's just not used during I/O. POSIX sayeth: 46244 The behavior of lseek( ) on devices which are incapable of seeking is implementation-defined. 46245 The value of the file offset associated with such a device is undefined. 46259 [EINVAL] The whence argument is not a proper value, or the resulting file offset would 46260be negative for a regular file, block special file, or directory. Best, наб signature.asc Description: PGP signature
Re: lseek on tty
> On NetBSD and macOS, lseek(2) on a tty succeeds: > if (lseek(STDIN_FILENO, 0, SEEK_CUR) == -1 ) > On Linux, this fails. > I'm trying to think of why seeking on a terminal would make sense. > Anybody have an idea? Quoting from lseek(2) on a handy machine: Some devices are incapable of seeking. The value of the pointer associated with such a device is undefined. So I'm guessing it depends on whether you think of adding something to an undefined value makes sense. To me, it does; the resulting value is undefined, but the seek pointer is undefined anyway. Also, I'd argue that lseek(,0,SEEK_CUR) makes sense on any descriptor, since it's not trying to change anything. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
