Open sc0ttj opened 5 years ago
The best way to start is to propose the interface in a PR, to iron out any usage or user experience issues..
For example, someone might propose a CLI advert blocker:
# /usr/sbin/advert-blocker --help
Commands:
list list all block list providers
install <provider> add the blocklist to /etc/hosts
remove <provider> remove the blockist from /etc/hosts
Options:
--help show this help message
--version print program version
After seeing the intended CLI described above in a PR, people could suggest fixes, improvements, new features, easier syntax, etc.
Then it can be built, reviewed etc, before being merged..
One thing we can do is to document, test and use pre-existing command line programs.
There are many good Python, Perl and Bash scripts which would work "out of the box" and provide very user-friendly ways of doing difficult things.
For example, colordiff (replacement for diff,more colourful.. also see diff-so-fancy
)
Or ranger
, is a very powerful file manager for the terminal, which could be included in the main SFS, or devx (for power users).. It can preview all kinds of files in the terminal, even PDFs, etc.
Or nnn
, a file manger in the terminal, lighter than ranger.
There are many "Awesome" lists on Github showcasing these programs, and many scattered around the forum.
Which leads me to another suggestion: https://github.com/puppylinux-woof-CE/woof-CE/issues/1628
Add proper support for skipping words, lines, etc in /etc/inputrc
:
# Word navigation
# Ctrl-Left/Right: skip whole words
"\eOc": forward-word
"\eOd": backward-word
# Other potential entries for Ctrl-Left/Right
"\e5c": forward-word
"\5d": backward-word
"\e[5C": forward-word
"\e[5D": backward-word
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word
"\e\e[5C": forward-word
"\e\e[5D": backward-word
"\e\e[1;5C": forward-word
"\e\e[1;5D": backward-word
# Alt-left, Alt-right: skip whole words
"\e[1;3C": forward-word
"\e[1;3D": backward-word
# Other potential entries for Alt-Left/Right
"\e3c": forward-word
"\e3d": backward-word
"\e[3C": forward-word
"\e[3D": backward-word
"\e\e[3C": forward-word
"\e\e[3D": backward-word
"\e\e[1;3C": forward-word
"\e\e[1;3D": backward-word
# for linux console
"\e[5~": beginning-of-history
"\e[6~": end-of-history
"\e[3~": delete-char
"\e[2~": quoted-insert
"\e[1~": beginning-of-line
"\e[4~": end-of-line
# for xterm
"\eOH": beginning-of-line
"\eOF": end-of-line
Ctrl-X,<key>
macros:# BASH keyboard macros (Ctrl-x,<something>)
$if Bash
# Ctrl+x, then p
# Edit the path
"\C-xp": "\C-a\C-kexport PATH=${PATH}\e\C-e\C-a\ef\ef\C-f"
# Ctrl-x,then l
# Edit the library path
"\C-xl": "export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}\e\C-e\C-a\ef\C-f"
# Ctrl-x,then c
# Edit the cd path
"\C-xc": "export CDPATH=${CDPATH}\e\C-e\C-a\ef\C-f"
# Ctrl-x, then "
# prepare to type a quoted word:
# insert open and close double quotes
# and move to just after the open quote
"\C-x\"": "\"\"\C-b"
# Ctrl-x,q
# Quote the current or previous word
"\C-xq": "\eb\"\ef\""
# Ctrl-x,r
# Refresh the line
"\C-xr": redraw-current-line
# Alt-Backspace
# delete word before cursor
"\e\e\C-h": backward-kill-word
# Alt-Delete
# delete word after cursor. (Alt+D by default)
"\e[3;3~": kill-word
"\e\e[3;3~": kill-word
$endif
PS1
I'm not suggesting we copy mine, but this screenshot demos the following features:
^ that's the main benefit.. but also:
Deja Vu Sans Mono
ls
, with icons and colours.. uses exa
.. very large binary :/ cd
command that runs ls && source .env
after each cd
(and more)See https://gitlab.com/sc0ttj/dotfiles for lots of cool Puppy CLI stuff.
While we should always have a UNIX-style CLI available, we should remember some (many) users avoid the command line cos "it's too much typing" or "too much reading".
They don't want to type commands.
We could/can use ncurses
, but many say it's ugly or scary.
However...
We can also use our preferred "terminal picker", like fzf
, picky
, fff
or similar, to make colourful, easy-to-use terminal menus for our CLI programs.
Some pickers:
Here's a list of liquid filters that can be used in the terminal:
https://github.com/sc0ttj/mdsh/blob/gh-pages/.app/functions/liquid_filters.bash
There are lots of "filters" ... Best used by sourcing it in a script to keep the rest of the code cleaner ... They aim to replace stuff like sed
with much easier things:
echo "$something" | replace_first 'oldword' 'newword'
And provide new things:
echo 1000 | money £
Decide on the best, fastest, statically compiled terminal picker, and a small dialog
statically compiled and put them into the initramfs, so every Puppy has ncurses
and pick
available right from boot..
Nobody probably knows but many small apps are cli/gui apps in a single script, may not be very nice to have cli/gui in the same script, but it's already there.
But the big apps certaintly aren't.
I have a working cli network manager derived from fatdog... well it was working 2 years ago. cli/gui .. I was about to integrate into woof 2 years ago, but the gui implementation was not finished and probably needed more fixes.
The truth is that you can't expect miracles, people do what they want at their own pace, the only way to make them work as a team is through money under contract. woof-CE is the living proof where basically none of the members know what the others are doing.
Your inputrc is already in woofce, you opened the PR, waited a few minutes, closed it and deleted your fork.
Nov 2018 https://github.com/puppylinux-woof-CE/woof-CE/blob/testing/woof-code/rootfs-skeleton/etc/inputrc
Thousands of improvements happened, but nobody noticed. Basically because puppy was so broken that fixing it a bit does take thousands of small fixes and improvements.
Some things are not possible with woof without a huge amount of effort, but they are possible with the debiandogs and so on, which is a subtle layer above debian.
Nobody probably knows but many small apps are cli/gui apps in a single script,
Everyone knows this... It's the problem I want to address.
I have a working cli network manager derived from fatdog... well it was working 2 years ago. cli/gui .. I was about to integrate into woof 2 years ago, but the gui implementation was not finished and probably needed more fixes.
I have a few different ncurses wifi tools I found.. some work, some need fixing up.. The Uis are fine, but I know nothing about wpa_supplicant..
Your inputrc is already in woofce, you opened the PR, waited a few minutes, closed it and deleted your fork.
That's nice... Didn't realise it got merged in, especially as I had to add it all in manually in Dpup Stretch to make it work..
Thousands of improvements happened, but nobody noticed.
Maybe if we had nicer docs - proper READMEs, nice commit messages, proper branches and PRs with good descriptive READMEs, separate repos for each important puppy program - then these changes wouldn't be so hard to find/see - there would be a lot more READMEs surfaced straight to the user as they browse the code/repo history.
The truth is that you can't expect miracles, people do what they want at their own pace
Every single time I make a suggestion I am met with this same response.. I am not expecting people to simply do my bidding, but trying to start a discussion about a better way forward...
Anyway... I will certainly create a split_cli_from_gui
branch, and create a branch off that called split_cli_from_gui--advert-blocker
, and I will make advert blocker separate CLI and GUI apps...
I will do a nice PR readme, with checkboxes and example/template code for others to use in their own .. Should get the ball rolling at least... The proof will be in the pudding.
I can create a new repo or a branch for my network manager, or maybe a
single repo for everything in experimental state, something like
staging
. It's small enough.
My netwiz contains code from:
The unfinished GUI is woofce-specific, the cli might be more generic. Providing stuff compatible with all puppy versions and universal stuff for everyone is not my goal.
It's meant to replace network wizard and SNS and become da built-in network manager. It's simple and advanced, but unfinished. It's one of the many unfinished projects I have.
rserwin1 might want to take look at the code, it's a bit old by now, but
I read that peasy wifi might contain the best code to deal with wifi
I think it's about reading and applying the best code no matter where it comes from, as long as it can be ported and applied successfully... integrating somebody else's code is a huge task.
Creating repos and commenting on git is as far I'll go. But it's almost Christmas, I may become quite busy anytime. 2020 will be a different year.
This is a general request:
Let's make the Puppy CLI easier and more powerful... A range of command-line programs for setting up the system, with:
puppy-installer
puppy-wifi
puppy-bluetooth
puppy-samba
puppy-xorg
puppy-wm
puppy-rescue
(fix windows registry, remove passwords, etc)puppy-help
(custom menu, usestldr
,man
,howdoi
,cheat.sh
, etc)--help
,--version
, etc)Programs with a good CLI make it easier to:
Any program that requires a GUI will have most of these problems:
xdotool
etc)In contrast, CLI programs are:
Create a
split_cli_from_gui
branchLet's start a branch in which the sole purpose is to separate Puppy programs from their GUIs, leaving separate CLI and GUI versions of each.
We can tackle one program at a time, and merge them into
testing
as each one is done.A PR for each program
Each program done should get its own PR, and each PR should:
Identify one program that is GUI only (and cannot be used without X) or very complex to use in terminal
Lets assume it's called
programX
.programX
programX
GUI toprogramX-gui
, make it use the CLI scriptStart with important system and setup programs which would greatly improve the non-X experience of Puppy, if they had easy CLI interfaces..
Creating command line interfaces
We could use a barebones, generic shell script template that parses command line arguments options robustly, and use that as a basis for our CLI scripts.
It could give us the important things "out of the box" and be a good "hello world" or template, setup by default to provide:
--help
option--version
option--config <file>
optionPrograms that could do with a good CLI:
Other benefits
We would end up with a much more powerful no X puppy, that was easier to use for beginners.
We would have a collection of programs that could be combined via a nice ncurses multi-menu .. A non X replacement of the JWM menu, for example.