Great, a few more decades and it might become a usable bugtracker.
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
In my opinion it should remain a shell thing. Adding tilde expansion just complicates the implementation of the tool. Now you need to know the current users home directory.
And some tools might implement it incomplete so that '~' works but '~name' does not work.
In POSIX shells '~name' expands to the home directory of user 'name'
$ echo ~bin
/bin
Now your tool need a way to query home directory for any user including system users. Depending on NSS configuration this is more complicated than just reading /etc/passwd.
All for the rare case that someone passes a file path starting with tilde and wants it to be expanded. IMO, when you provide a file interactively you do so through a shell and tilde expansion is handled by the shell and otherwise just provide the actual file path and do not rely on the tool doing additional expansions.
PS: I mixed up TUI and CLI program a bit in my head. For an interactively used TUI program it might be beneficial to implement tilde expansion (but then it should be as complete as in Shells). A CLI program should not do magic stuff like tilde expansion.
I remember reading some rant about how Unix sucks because of the shell's filename expansion, because programs can't tell whether you wrote a star or actually just all the files in the directory. If programs could tell the difference, then you could get the desired renaming behavior from mv like this:
mv *.m *.c
They suggested that this filename expansion should be in the C standard library, not the shell.
Going further, as part of shell expansion, expanding the tilde could also be useful for filename expansion in the standard library.
> And regardless of how you feel about the default the way they went about it broke things for users
For users using Debian unstable and even there it was apparently fixed/improved after a week.
Debian stable users had no "wild ride" and for the future became the choice to select between the full featured keepassxc version and a minimal variant without non-essential network and IPC features.
> [ERROR] No goals have been specified for this build.
> [ERROR] Unknown lifecycle phase "build".
And somehow missed that the error message also lists the valid lifecycle phases. (could have instead complained that it list all lifecycle phases which is a lot)
> // me searching on google how to not run tests
How do I know for other build tools how to skip tests? Skipping tests should not be necessary and is done to regularly. I would not consider a tool which immediately points out how to ignore those stupid tests as good UX.
When I want to run tests, I tell it to run the tests. When I want to install, I tell it to install. I don’t want it to run tests when I tell it to install. I don’t want tools who know better what I want to do than me.
In most cases you could simply use a huge number of lines like
head filename -n 1000000000
or use the "inverse mode". Head and tail can print all but the first/last n lines (I just have trouble to remember without man page the syntax and which does what).
So those are more "cat equivalents":
head -n-0 filename
tail -n+0 filename
PS: for your wc example you could actually do just
head -n $(wc -l filename)
because `wc` will print the number of lines and the filename. (does not work with spaces)
Until you realize that some of the expressions in [[ are evaluated as arithmetic expression which has some surprises around array subscript and command substitution.
In short, because the following works despite quoting and will execute the echos
> OP is one of -eq, -ne, -lt, -le, -gt, or -ge. [...] When used with the [[ command, Arg1 and Arg2 are evaluated as arithmetic expressions (see ARITHMETIC EVALUATION above).
> ARITHMETIC EVALUATION
> Within an expression, shell variables may also be referenced by name without using the parameter expansion syntax.
> The value of a variable is evaluated as an arithmetic expression when it is referenced
> Arrays
> The subscript is treated as an arithmetic expression that must evaluate to a number.
> [[ expression ]]
> The shell performs [...] arithmetic expansion, command substitution [...] on those words.
Given that reading, that both subscripts and values of variables in arithmetic expression are treated as arithmetic expressions, and that command substitution is peformed after arithmetic expansion in `[[`, I kinda expected the following to work:
I don't fully understand what's going on here, but note that arithmetic expansion is for stuff like $((6 * 7)). There's no arithmetic expansion involved in your or
Calzifer's examples.
>> The shell performs [...] arithmetic expansion, command substitution [...] on those words.
> [...] and that command substitution is peformed after arithmetic expansion in `[[` [...]
You're right. That doesn't apply. I was equating "arithmetic expansion" with "evaluation of arithmetic expressions", but I see now the former is specifically about `$(())`.
Reminds me of the good old times of first generation Google ReCaptcha where I always only entered the one word Google knows and ignored or intentionally mistyped the other.
> Based on our qualitative observations, participants’ long navigation times in Eclipse appeared largely due to time spent scrolling through files full of irrelevant code (as opposed to switching tabs), and failing to see the methods they wanted among that code.
> [...]
> Because users of Code Bubbles and Patchworks were able to open code at the granularity of methods, they had the advantage of never having to scroll through code to reach their navigation targets.
Have only read a bit of this paper but from this discussion over Eclipse it seem that the participants could be a lot more efficient if they used it more like an IDE than a multi-tab editor.
Finding methods should be much less of an issue having an (alphabetically ordered) outline view.
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
reply