Proposal: increase tce-an screen selction from 15 to 20 items

[nick65go]

Hi, in /usr/bin/select (of 1332 bytes), we see a list of max 15 lines / items.
Most machines/PC have (even in console) 25 horizontal lines / rows.
Subtracting 3 row (header) + 2 rows (footer) from 25, still allows for 20 lines to list. May we have the changed "j" counter to max 20?

Attached my proposal select file and its diff patch:

Code: [Select]

diff -a select 2select > select.diffI did increase to 20 items/screen, set full path to awk and bypass usebusybox and tc-functions (there are none in this script). I tested it in aterm.

[GNUser]

Hi nick65go. useBusybox is TCL's conventional way to force a script to use busybox utilities when other versions of those utilities (e.g., GNU coreutils) might also be present. tc-functions provides the useBusybox function, so tc-functions is in fact being used here (if only in a trivial way).

It's generally best to use function libraries, follow project conventions, and avoid absolute paths. Just a fellow user's two cents. Granted, this fellow user is a stiff and old-fashioned dinosaur.

[Rich]

Hi nick65go
Do not replace  useBusybox  with hard coded paths. Eventually it will cause
something to break. System scripts are written to use busybox commands
because they are guaranteed to be present. They rely on the behavior of
those commands.

This is one of the aliases provided by  useBusybox:

Code: [Select]

awk() {
    busybox awk "$@"
}This calls  busybox  with  awk  as a parameter. This ensures that as long as
busybox  is in the search path, the  busybox version of  awk  will be used.

Currently some of the links to  busybox  are in  /bin  and some are in  /usr/bin.
I suspect at least some of the  busybox  links in  /usr/bin  are there because some
programmer insisted on hardcoding the location of a command.

If any of those links ever change, anything hardcoded to those links can/will break.

useBusybox  adds robustness to scripts. Do not create vulnerabilities by hardcoding
paths for commands.

[curaga]

I agree, please do not hardcode paths. The number increase alone is fine.

[nick65go]

when someone tells you that you are drunk, it is likely that you are. but when more people tell you that, then it is certain.
OK, lesson learnt. Nice/ constructive talk, thank you.
PS: The stake is small, but is good to try my hand on. I am lazy, I like more to suggest ideas than to do it wrong, because the language syntax.

[GNUser]

...I am lazy...

I think most programmers are Which is why rules of thumb such as DRY (don't repeat yourself--an application of which is function libraries) and avoiding absolute paths are popular: They minimize risk of breakage and make things easy to fix if things do break.

If I had a dollar for every time an absolute path in one of my own projects bit me...