Hi Evgeniy,
On Sun, 12 Apr 2026 at 19:56:41 +0300, Evgeniy Berdnikov wrote:
> On Sun, Apr 12, 2026 at 04:14:22PM +1000, Seth McDonald via isync-devel wrote:
> > + errno = 0;
> > + if (!isatty( fd )) {
> > + if (errno != ENOTTY)
> > + sys_error( "Cannot examine file descriptor %d", fd );
>
> Absence of terminal is not an error, this is normal situation, such as run
> in batch job or systemd service.
Indeed. That's why it's checking if errno is _not_ ENOTTY. See the
POSIX.1-2024 entry for isatty()[0]:
| The isatty() function may fail if:
[...]
| [ENOTTY]
| The file associated with the fildes argument is not a terminal.
If fd is not a terminal, errno will be set to ENOTTY, meaning the error
message will not appear. But if errno is not set to ENOTTY, then the
isatty() call failed for a reason other than "not a terminal" (probably
an invalid file descriptor). This is an error that should be logged,
because it indicates something is wrong with the program state.
> > + const char *term = getenv( "TERM" );
> > + if (term && !strcmp( term, "dumb" ))
> > + return 0;
>
> You are assuming all terminals different from "dumb" do support vt100-like
> escape sequences. This is almost true, because other terminals are
> historical artefacts. Moreover, in case of undefined TERM this code produces
> escape sequences. I think it should not be.
I actually just attempted to mimic the behaviour of git-status here. I
ran `TERM=... git status` a few times, with TERM set to different
values, and found that - of the values I tested - only TERM=dumb removed
the coloured output.
I figured it would be better to defer the wanted behaviour to those of
common existing programs, as this would integrate nicely in environments
that users may have already curated for such behaviour. Though I am
open to adding custom behaviour if that's what's wanted.
> You have better to check explicitly at least for "xterm", "linux" and "vt100"
> (with account for suffixes after "-" character, as term(7) and terminfo(5)
> stated), and do not use vt100-like escapes for unknown/undefined terminals.
So you're saying we should default to not using escape sequences unless
the terminal is known to support them (as opposed to defaulting to using
them unless the terminal is known to not support them)? I'd imagine
we'd have to cover a lot of cases to be portable, which is possible, but
IMO not really the best use of time.
Take care,
Seth McDonald.
[0] <https://pubs.opengroup.org/onlinepubs/9799919799/functions/isatty.html>
--
E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51
_______________________________________________
isync-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/isync-devel
