The "we have more than 5 senses" insistence, while interesting, misconstrues what is typically understood as a "sense" by the average person.
When children are taught what the 5 senses are, i.e. seeing, hearing, touch, taste and smell, these are more literary senses than scientific ones. (In another vein, it's like disagreeing whether a tomato is a vegetable, fruit, or both -- scientists and cooks have different definitions!)
Proprioception, the unconscious spatial perception of your body parts, falls under "feel." Hunger and thirst do, too. I feel hungry, I feel that my leg is below me, I feel off-balance. These scientifically-defined senses fall under one literary sense or another.
Since this is just a mangling of definitions, it's almost irresponsible to call the five-senses thing a misconception. That being said, it did interest me; did you know that endolymph fluid in our ears uses its inertia to tell us what's going on when we turn our heads? ツ
Stunningly simple, solely a shift. I love MVPs... we can possibly even remove the -P
completion func switch :P
How do I add autocompletion for my stfu
command?
I have a little helper command in ~/.zshrc
called stfu
.
```
stfu() {
if [ -z "$1" ]; then
echo "Usage: stfu <program> [arguments...]"
return 1
fi
nohup "$@" &>/dev/null &
disown
}
complete -W "$(ls /usr/bin)" stfu
`stfu` will run some other command but also detach it from the terminal and make any output shut up. I use it for things such as starting a browser from the terminal without worrying about `CTRL+Z`, `bg`, and `disown`.
$ stfu firefox -safe-mode
Will not output stuff to the terminal, and
I can close the terminal too.
``` Here’s my issue:
On the second argument and above, when I hit tab, how do I let autocomplete suggest me the arguments and command line switches for the command I’m passing in?
e.g. stfu ls -<tab>
should show me whatever ls’s completion function is, rather than listing every /usr/bin
command again.
```
Intended completion
$ stfu cat -<TAB> -e -- equivalent to -vE --help -- display help and exit --number -n -- number all output lines --number-nonblank -b -- number nonempty output lines, overrides -n --show-all -A -- equivalent to -vET --show-ends -E -- display $ at end of each line --show-nonprinting -v -- use ^ and M- notation, except for LFD and TAB --show-tabs -T -- display TAB characters as ^I --squeeze-blank -s -- suppress repeated empty output lines -t -- equivalent to -vT -u -- ignored
Actual completion
$ stfu cat <tab> ...a list of all /usr/bin commands $ stfu cat -<tab> ...nothing, since no /usr/bin commands start with - ```
(repost, prev was removed)
EDIT: Solved.
I needed to set the curcontext
to the second word. Below is my (iffily annotated) zsh implementation, enjoy >:)
``` stfu() { if [ -z "$1" ]; then echo "Usage: stfu <program> [arguments...]" return 1 fi
nohup "$@" &>/dev/null & disown } #complete -W "$(ls /usr/bin)" stfu _stfu() {
Curcontext looks like this:
$ stfu <tab>
:complete:stfu:
local curcontext="$curcontext" #typeset -A opt_args # idk what this does, i removed it
_arguments \ '1: :_command_names -e' \ '*::args:->args'
case $state in args) # idk where CURRENT came from if (( CURRENT > 1 )); then # $words is magic that splits up the "words" in a shell command. # 1. stfu # 2. yourSubCommand # 3. argument 1 to that subcommand local cmd=${words[2]} # We update the autocompletion curcontext to # pay attention to your subcommand instead curcontext="$cmd"
# Call completion function _normal fi ;; esac } compdef _stfu stfu ```
Deduced via docs (look for The Dispatcher), this dude's docs, stackoverflow and overreliance on ChatGPT.
EDIT: Best solution (Andy)
``` stfu() { if [ -z "$1" ]; then echo "Usage: stfu <program> [arguments...]" return 1 fi
nohup "$@" &>/dev/null & disown } _stfu () {
shift autocomplete to right
shift words (( CURRENT-=1 )) _normal } compdef _stfu stfu ```
At a level that the user doesn't have much control over, I fear both stock systems are about the same in terms of privacy.
According to an analysis by Köllnig et al. (2021) on 500k+ free Google Play/App Store apps, tracker libraries such as Google Play Services/Apple's SKAdNetwork/cross-platform libraries are used in about equal percentages on both app stores' free apps. These free apps' trackers are generally not configured to follow GDPR data-minimization practices, even for kids' apps, but it's to be noted that Android has a disadvantage in that advertising ID is more used in Android apps than Apple apps. However, Apple has disadvantage too: the researchers noted that Android's intent system and different permission model makes apps seem "more privileged" than Apple's, but Apple makes accurate analysis of their apps' reach difficult, judging by the larger failure rate in app decompilation as well as the more opaque approach to permission disclosure. Although the paper might imply Apple has improved over time, since it mentions Apple's implementation of opt-in tracking in 2021, after the study, as a limitation, keep in mind Apple's new movement towards advertising as a form of revenue, as discussed by Apple Insider (Owen, 2022) and Bloomberg (Gurman, 2022).
Of course, Köllnig's study only reflects tracking in "curated apps" for either platform. It does not discuss hardware/firmware/system app-level privacy, which users have little control over (Leith, 2021 -- easier reading with TomsGuide). Leith found that either OS phones home (lol) every ~4.5 minutes, and even though Google may send more data (even from the clock app!), Apple profiles your social network via MAC addresses on your Wi-Fi as well as location geotagging, which the TomsGuide article called "quality vs. quantity". This builds on the idea that Apple might seem more private, but only ostensibly so, judging by these more particular looks at their data collection and the trend of their increasingly data-focused business model.
Does that mean the choices between stock OS don't matter? Well, no -- as for me, who can't afford a Pixel anytime soon, I've chosen Android on account of freedom outside of curated app stores. Yes, PrivacyGuides may not recommend F-Droid, but the opportunity cost in security there may be negligible compared to the convenient and easily-handled privacy received in exchange*, at least for typical less-savvy threat models like my own. (This favorability is illustrated in a forum debate here (Lukas, 2023), though in a context less relevant to stock OS comparisons.) Ignoring the facet of freedom with stock Android, the possibility of large privacy advantage one way or the other, strictly in terms of stock Android and stock iOS operating systems, is marginal if it even exists.