Kurtis Rader comments

Results 691 comments of


                                            Kurtis Rader

Embedded command documentation needs to be moved outside the C source files

I have been chipping away at converting builtin commands from the DocOpt style documentation and flag definition used by the AST `optget()` function to Sphinx/reStructuredText and `getopt_long()`. 95% of the...

Embedded command documentation needs to be moved outside the C source files

Also, this work has brought to light more instances where the documentation for a builtin command in the `ksh(1)` man page differs from the actual implementation. For example, `cd` supports...

Embedded command documentation needs to be moved outside the C source files

I just found another "gotcha". It looks like `optget()` defaults to **POSIXLY_CORRECT** behavior. Which is not surprising. But that behavior requires `+` to be the first char of the `getopt_long()`...

Embedded command documentation needs to be moved outside the C source files

Converting the `b_umask()` function to use `getopt_long()` should have been straightforward. It wasn't because of this line in the `infof()` function in *src/cmd/ksh93/bltins/ulimit.c*: ``` sfprintf(sp, "[%c=%d:%s?The %s", tp->option, tp -...

Embedded command documentation needs to be moved outside the C source files

Note that my previous comment applies to the ksh93u+ release. That `optget()` behavior seemingly exists solely for the use of the `b_umask()` function. **There is no other place in the...

Embedded command documentation needs to be moved outside the C source files

The flag parsing by the `ksh`, `set`, and `typeset` commands depends on the AST `optget()` handling flags that begin with a `+` rather than `-` char. The platform `getopt_long()` provided...

First multi-byte character not being read correctly when run on the client side of a rlogin connection

Are you saying this works correctly with the ksh93u+ release (from 12 years ago) but not the current version? You did not tell us which ksh version you are using....

First multi-byte character not being read correctly when run on the client side of a rlogin connection

Also, what ksh statement results in the `ksh: ¿¿¿¿: not found [No such file or directory]` output?

First multi-byte character not being read correctly when run on the client side of a rlogin connection

@rphaniram FWIW, when reporting Unicode related issues you should use the `U+3042` notation for a code point rather than the `E38182` UTF-8 hex sequence for the codepoint. It wasn't until...

First multi-byte character not being read correctly when run on the client side of a rlogin connection

I am very confident this has nothing to do with ksh per se. Mostly because neither of us sees the problem when rlogin is not part of the equation. It...