[9front] [PATCH] syscall: utility overhaul

[9front] [PATCH] syscall: utility overhaul

[ori]

Following is a list of functional changes:

* The -o flag outputs the entire buffer to the length returned
  by the syscall, or, in case of fd2path(2) and errstr(2), to '\0'.
* The -x flag is removed; the above makes it possible to pipe
  into xd(1) to get the same result.
* The -s flag uses dirfmt(2) to format the stat message, instead
  of trying to imitate ls(1).
* Stderr reports are normalized and made easier to parse.

The code also suffered a number of stylistic changes.

diff -r d947a4c5d7fa sys/man/1/syscall
--- a/sys/man/1/syscall	Thu Sep 03 20:07:44 2020 -0700
+++ b/sys/man/1/syscall	Sat Sep 19 15:04:17 2020 +0200

+		switch(i){
+		case _ERRSTR: case ERRSTR: case FD2PATH:
+			nbuf = strlen(buf);
 		}

Is buf guaranteed to be nul terminated here? I think
we're likely to be ok here, but I'd be more comfortable
if we had the last byte explicitly set before calling
strlen.

Other than that, it lkooks good to me.

Re: [9front] [PATCH] syscall: utility overhaul

[ori]

> Following is a list of functional changes:
> 
> * The -o flag outputs the entire buffer to the length returned
>   by the syscall, or, in case of fd2path(2) and errstr(2), to '\0'.
> * The -x flag is removed; the above makes it possible to pipe
>   into xd(1) to get the same result.
> * The -s flag uses dirfmt(2) to format the stat message, instead
>   of trying to imitate ls(1).
> * Stderr reports are normalized and made easier to parse.
> 
> The code also suffered a number of stylistic changes.
> 
> diff -r d947a4c5d7fa sys/man/1/syscall
> --- a/sys/man/1/syscall	Thu Sep 03 20:07:44 2020 -0700
> +++ b/sys/man/1/syscall	Sat Sep 19 15:04:17 2020 +0200
> 
> +		switch(i){
> +		case _ERRSTR: case ERRSTR: case FD2PATH:
> +			nbuf = strlen(buf);
>  		}
> 
> Is buf guaranteed to be nul terminated here? I think
> we're likely to be ok here, but I'd be more comfortable
> if we had the last byte explicitly set before calling
> strlen.
> 
> Other than that, it lkooks good to me.

(Actually, ignore that, those syscalls nul terminate)

Re: [9front] [PATCH] syscall: utility overhaul

[kvik]

> If a user redirects this output to a file and tries to edit it,
> sam and acme will remove the \0 bytes and issue a warning on load.
> Ed doesn't warn, but truncates lines at \0. Just raising the issue in
> case it's relevant. IMO, these are minor bugs in our editors.

This is not something that syscall(1) should worry about.  If you asked
to do a syscall, then you must expect to get the result of a syscall.

> > * The -x flag is removed; the above makes it possible to pipe
> >   into xd(1) to get the same result.
> 
> I'm not familiar with syscall, but is it really the same result?

It's not, at least not by default.  However, you can invoke xd(1) in just
the right way to get the /same/ result, if you so please.

Re: [9front] [PATCH] syscall: utility overhaul

[Ethan Gardener]

On Sat, Sep 19, 2020, at 2:05 PM, kvik@a-b.xyz wrote:
> 
> * The -o flag outputs the entire buffer to the length returned
>   by the syscall, or, in case of fd2path(2) and errstr(2), to '\0'.

If a user redirects this output to a file and tries to edit it, sam and acme will remove the \0 bytes and issue a warning on load. Ed doesn't warn, but truncates lines at \0. Just raising the issue in case it's relevant. IMO, these are minor bugs in our editors.

> * The -x flag is removed; the above makes it possible to pipe
>   into xd(1) to get the same result.

I'm not familiar with syscall, but is it really the same result?