Features, Maintainability, & Style changes#8
Conversation
- removes the need to do it in either path future commit can further remove the need to set the subsequent vars
- increases maintainability & testability
- `echo` is not standardized across platforms
- increases maintainability and allows for clearer review of history
- removes usage of external tools `cat`, as `printf` is a builtin - easier to adhere to style since we no longer have tabs & spaces - reduces duplicate hardcoded strings
…ion|fn` - excludes `_type` option from help so its functionality is not misconstrued for working for more types
- allow status code to propagate down to end - increases maintainability and clarity
- added post & pre-warming logs to indicate the beginning and completion of the warming
- since `assert` begins counting as soon as is sourced, it is misleading to have it be sourced before we warm
|
@qzb |
|
Thanks for your PR, I'll try to review it today or tomorrow, but for now it looks great 😀 |
| * `is function NAME` - name is a function | ||
| * alternate(s) `fn` | ||
| * `is keyword NAME` - name is a keyword | ||
| * `is array NAME` - name is a variable |
There was a problem hiding this comment.
I guess it's kind of obvious, but still description should be more precise:
| * `is array NAME` - name is a variable | |
| * `is array NAME` - name is a variable of array type |
There was a problem hiding this comment.
If the intent of the README condition description is to tell you what you need to pass in to get a true resultant back, then yes. Would you want to update the rest of the type conditions to follow suite?
| if is equal $var 123.0; then | ||
| echo "it just works" | ||
| fi | ||
| $ is equal "$var" 123.0 && printf 'it just works!\n' |
There was a problem hiding this comment.
Why use printf in the examples? Isn't echo more common and easier to use (no \n at the end)?
There was a problem hiding this comment.
from what I recall, printf is more portable & consistent then echo across platforms
qzb
left a comment
There was a problem hiding this comment.
Some of new conditions work only when script is sourced. I think it should be described in README.md and help messages. Personally I would move all this conditions to separate section in README.
- `bash v3.2.57` doesn't support `declare -g`
- internal lowercasing is faster then `tr` so the minor speed reduction due to the conditional is worth it overall
- now it really won't leak when
- unfortunately, this relatively increased the test duration quite a bit 0-1s to 2-3s on v5 & 4-5s on v3.2.57
- to keep with backwards compatibility previously, you could write `not an not an the not a` but with the change to using a while loop for the articles whilst keeping its check after not, you lost the ability to do that
otherwise, the timing is not as percise
Good idea. I'll fix up the tests to reflect this as well. |
Note
I kept
cmd|commandseparate fromavailable|installedfor two reasons:command, is more complicated; see has
I intended for these changes to be separate PR's but I got caught up and it got
a little too tedious to re-structure the commits.
Since this doesn't break backwards compatibility, I've updated the version from
1.1.2->1.2.0Changes
features
--versionfollowed by--helpalias,builtin,keyword,function|fn,int|integer,array,hash|dictionary,export|exportedbool|boolean,truthy,falseycmd|commandinset|var|variable.editorconfig,.gitignoremaintainability
version&helpare in their own functionprintfoverheredoc+catprintfoverechoechodoesn't consistently behave the same across all systemsstyle
printfoverheredocto not have tabs or un-indented codeassert.sh: move code continuation so syntax highlighting in VSCode doesn'tmis-color the rest of the file
In the tests file, I kept reference to a bash bug I encountered when parsing the
keyword&builtin,[[]]&[], respectively. I can add a note about what version this was found in.