https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235589
--- Comment #6 from Jilles Tjoelker <jil...@freebsd.org> --- This is quite nice, but please run the tests (basically, cd /usr/tests/bin/sh && kyua test) and add new tests for $((LINENO)). Existing tests should not be modified unless they were broken or too specific. I think NCASE and NFOR nodes should also contain a line number. An earlier version of the patch did a simple 32-bit integer write during execution, leaving the snprintf(..., "%d", ...) to when LINENO was expanded. I liked that better. There could be a VLINENO flag indicating LINENO's struct var (and that it is still special, see below). Making LINENO readonly matches zsh but I found some obscure scripts searching for "LINENO=" on codesearch.debian.net (such as https://sources.debian.org/src/opentmpfiles/0.2+2019.05.21.git.44a55796ba-2/tmpfiles.sh/?hl=443#L443 ) that assign values to LINENO and will then break. Currently, this is accepted but has almost no effect, so completely ignoring assignments is probably quite safe. This also seems to happen in bash. In ksh variants, assigning to LINENO changes an offset for future LINENO expansions (for example, if line 10 contains LINENO=1010, future LINENO references will result in a line number 1000 more than normal; a bit like #line in C). I suggest not implementing this because it will not work well with the current design for line numbers within functions. In both bash and ksh, unsetting LINENO makes it a normal variable, and the only way to expand line numbers again is to restart the shell. Implementing this may or may not be worth it. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
