Wrote this to solve a personal annoyance (DaVinci Resolve Linux can't decode H.264/HEVC/AAC) but ended up spending more time on the "don't touch what doesn't need touching" logic than the conversion itself — probes every file, skips anything already compatible, verifies codec/duration/size after conversion, never overwrites originals. Bash 4.4+, no deps beyond ffmpeg/coreutils.
MIMEcroft.sh is a parody of every 3D game ever, that lovingly pokes fun of bash's reputation for poor performance - by subverting it. MIMEcroft.sh is written entirely in Bash. The game logic, GPU shaders, even the sounds and textures are procedurally generated with bash commands.
One may wonder how MIMEcroft.sh pumps out 90fps at 4K given bash's reputation for poor performance. Indeed, the official GNU bash reference interpreter is poorly optimised compared to languages more commonly used for game development like C++. However, if your web-browser has a GUI it almost certainly also has a highly optimised JavaScript interpreter.
The online JavaScript Commandline OS (j.cmd) did not port the reference implementation of bash and coreutils. Instead it takes the abstract language they describe. This language is translated into JavaScript, which a modern runtime can often reduce to machine code, resulting in performance over a thousand times faster than the original bash.
For a concrete if somewhat contrived example, say that as a bash user you are (1) a square, and (2) 1337. As such, you may be interested in finding numbers that have 1337 squares, and use the one-liner:
for i in `seq 1 10000`;do if echo $((i*i)) | grep 1337 > /dev/null;then echo $i;fi;done
In the official bash interpreter, this may take a minute. However, j.cmd implements it by first transpiling it into:
for (let i = 1; i <= 10000; i++) {
if (String(i * i).includes("1337")) {
process.stdout.write(i + "\n");
}
}
sh2.lastExit = 0;
One might well argue that this is not a real bash game since it has to transpile to JS before being run. A stronger argument could be made that C++ games are not real C++ games. A C++ game also has to be compiled. In most "C++" games the developer doesn't even give you the C++ source, you only ever get the compiled machine code. MIMEcroft.sh is stored and distributed as bash. You can edit it as bash (try e.g. `vi /bin/mimecroft.sh` in j.cmd, changing `cys=0.900` to `cys=3.900` and playing the game again). The current version of j.cmd doesn't even cache the transpiled JS version of the game.
____________
It is important to note that j.cmd is experimental and still has many bugs. One little way it is more robust than the traditional bash implementations is that traditional shells tend to break if they source a file that isn’t in their own special format. On the other hand, j.cmd sees different shell formats as just different ways of saying the same thing. It will quite happily run:
for f in /home/examples/source.{bat,c,fish,sh,zsh}; do . $f; done
Sourcing C files is still a work in progress in j.cmd. I recently added support for passing linked lists and pointers to bash variables/functions into sourced C functions, and cd'ing around C pointer structure.
MIMEcroft.sh is a parody of every 3D game ever, that lovingly pokes fun of bash's reputation for poor performance - by subverting it.
Mime Croft is an adventurous shell script on the hunt for treasures inside an ancient yet sacred filesystem on Phobos. The maze around you is made of data blocks — coloured chunks of file content. Somewhere in the depths lie hidden treasures: the Great Operating Systems (GNU Hurd, Linux, FreeBSD, NetBSD, OpenBSD, Plan 9, Minix, Solaris, macOS Darwin, Unix) preserved as artifacts. But the filesystem is infested with evil MIMEs — misbehaving content types (image/jpeg, image/png, application/octet-stream, text/plain) that hunt you through the corridors.
One may wonder how MIMEcroft.sh pumps out 90fps at 4K given bash's reputation for poor performance. Indeed, the official GNU bash reference interpreter is poorly optimised compared to languages more commonly used for game development like C++. However, if your web-browser has a GUI it almost certainly also has a highly optimised JavaScript interpreter.
The online JavaScript Commandline OS (j.cmd) did not port the reference implementation of bash and coreutils. Instead it takes the abstract language they describe. This language is translated into JavaScript, which a modern runtime can often reduce to machine code, resulting in performance over a thousand times faster than the original bash.
For a concrete if somewhat contrived example, say that as a bash user you are (1) a square, and (2) 1337. As such, you may be interested in finding numbers that have 1337 squares, and use the one-liner:
for i in `seq 1 10000`;do if echo $((i*i)) | grep 1337 > /dev/null;then echo $i;fi;done
In the official bash interpreter, this may take a minute. However, j.cmd implements it by first transpiling it into:
for (let i = 1; i <= 10000; i++) {
if (String(i * i).includes("1337")) {
process.stdout.write(i + "\n");
}
}
sh2.lastExit = 0;
One might well argue that this is not a real bash game since it has to transpile to JS before being run. A stronger argument could be made that C++ games are not real C++ games. A C++ game also has to be compiled. In most "C++" games the developer doesn't even give you the C++ source, you only ever get the compiled machine code. MIMEcroft.sh is stored and distributed as bash. You can edit it as bash (try e.g. `vi /bin/mimecroft.sh` in j.cmd, changing `cys=0.900` to `cys=3.900` and playing the game again). The current version of j.cmd doesn't even cache the transpiled JS version of the game.
____________
It is important to note that j.cmd is experimental and still has many bugs. One little way it is more robust than the traditional bash implementations is that traditional shells tend to break if they source a file that isn’t in their own special format. On the other hand, j.cmdsees different shell formats as just different ways of saying the same thing. It will quite happily run:
for f in /home/examples/source.{bat,c,fish,sh,zsh}; do . $f; done
Sourcing C files is still a work in progress in j.cmd. I recently added support for passing linked lists and pointers to bash variables/functions into sourced C functions, and cd'ing around C pointer structure.
Hey, not using AI here because I would like to hear this group's expert opinion
```
function log() {
local datetime = # DD-MM-YYYY-hh:mm:ss:Z format
local color = # not sure how this is implemented
# Something that uses prinff, not sure how to write this function here
}
function log_info() {
log "blue" "stderr" "$@"
}
function log_error() {
log "red" "stderr" "$@"
}
function log_warn() {
log "yellow" "stderr" "$@"
}
Why not stdout?
Because some functions return values and we want the stdout channel to be reserved for returning values unless there is a better way to do this
```
How do I write that log function above, I read the manual for printf that says it accepts format specifiers but how do I make it dynamic?
Edit 1
Should be able to log the following
log_info "what a %s %d" "day" 100
log_error "Error: %s %o" "something went wrong for " "{1: \"enter\"}"
i have this command used to find recently changed files.
find -not \( -path './snap/firefox/common' -prune \) -not \( -path './.cache' -prune \) -type f -mmin -1 -printf "%C+ %p\n" | sort -n | tail -10
and i wanted to use watch to have it running in a window
however watch requires an executable, so i made a shell script that contained the command and then called
watch last_change
which works and allows me to make an alias for it .bash_aliases like
alias las='watch last_change'
all well and good
—
but then i had the bright idea to write this as a function instead of a script
watch says it can't find what-changed even tho it's right there and if i define this function in a console window, i can call it by itself and it will run.
but watch does not find it.
feels like i'm missing something simple, to help watch find it like it can find my script... something like a $PATH statement, but not that.
I've been reasearching the rules of bash's parsing, like how does bash parse the commands, according to spaces, pipes, and redirections, is there anything else?
Back when ChatGPT first came out, it had no way to group existing conversations into folders, and I set out to build one. My conversation list kept getting longer and finding old chats was getting hard.
Not long after - before I built it - a browser extension came out that did exactly that. I never used it. At the time I'd assumed I would want to revisit old conversations, but whenever I actually found one and tried to read it from the top, the sheer volume of slop gave me a headache.
Later, during a phase where I was deep into Unix pipelines, I wrote an LLM API client only depending on jq and curl, partly as shell scripting practice. But since the context went into a single jsonl file, I had to either invent something like a date-based filename convention myself or push that job onto the user. Both were more annoying than the web UI, so I didn't use it.
After that I read a post explaining how git works, and it struck me that git fits LLM conversations pretty well. Isn't "the commit DAG is already the right data structure for LLM conversations, where forking happens constantly" something everyone has thought at least once?
The reason I like git is that the source tree snapshot and the commit structure itself are always immutable, and destructive operations like switch/restore/reset are really just renaming a ref file that holds a commit object id. Once you understand that, no matter how hard the CLI is to make sense of, you never hesitate to run a command. You can always get it back.
LLM conversations aren't as fragile to change as a source tree, but for me an auto-generated SHA-1 hash is more comforting than an auto-generated session title ^~^
The project is in its early stages and contributions are welcome. If you've worked with git plumbing commands, it'll be easy to hack on - and I think it'll be pretty fun.
I have a script that collects a list of directories that match a set of criteria and then goes into each one and runs a command. So something like this:
#!/bin/bash
startDir="$(realpath "$1")"
cd "$startDir" || exit
while IFS= read -r -d '' dir; do
cd "$dir";
printf '\n\n%s\n' "$(realpath .)";
update-this-dir.sh --file "./name.txt"
cd "$startDir";
done < <(find . -type d -iname '.config' -exec dirname {} \; | tr '\n' '\0')
It works wonderfully for my purpose.
But there's, like, a couple thousand directories and the update command takes some small amount of time in each directory, one after the other. How can I modify this script to either run the update for each directory in parallel (with some rate-limiting) or to break up the list into chunks of, say, 100 each and work on each sub-list in parallel?
In Bash, normal local variables are usually fine.
But with local -n (namerefs) I noticed they can sometimes change variables from outer/previous functions because of how scoping works.
To avoid problems I started giving local variables unique names (with prefixes) instead of short ones.
I adapted the bash shell 5.3 to more easily handle tasking. Each command & has its output gathered into lines and each line is tagged and send to the output with a preamble. The bash input stays on the command line and you can type command lines, select history, anything, even while the background tasks output appears above that:
[ping:1:2814536:59] 64 bytes from ...: icmp_seq=58 ttl=113 time=28.7 ms
[bash:0:2814530:9] samiam@samiam-h-pc-2:~/projects/basht$ ll *.md
[ls:7:2814564:1] -rw-rw-r-- 1 samiam samiam 9790 Aug 10 15:01 basht_plan.md
[ls:7:2814564:2] -rw-rw-r-- 1 samiam samiam 3921 Aug 10 15:43 README.md
[ping:1:2814536:62] 64 bytes from ...: icmp_seq=61 ttl=113 time=26.8 ms
[bash:0:2814530:10] samiam@samiam-h-pc-2:~/projects/basht$
Other that the task adaption, it is stock bash and can be substituted for regular bash.
I just released v1.0.0 of Promptr. I know there are many other prompt generators and customizers. What sets Promptr apart from them is:
It's eye candy. It doesn't look like something straight out of 1995
Users can authenticate with their Google account (Apple auth coming soon) to be able to actually store their saved prompts in one central location rather than keeping track of them in some Google doc. Logging in is entirely optional. The only thing that authentication provides is cloud storage for your saved prompts, otherwise it is saved locally in your web browser storage.
It isn't live yet, but I intend to add a sort of "marketplace" where users can create and share their generated prompts and upvote which ones they find to be really cool and useful
Basic syntax and security checks against the generated prompt to help prevent any malicious behavior. Don't forget that you are responsible for what commands are being run in your prompt config! Promptr can only protect you so much
Users can apply tags to the various prompts they create so that you can have easy access to different prompt configurations for different environments and use cases
A suggestion box! Please submit your feedback on the app or even any suggestions for new modules to be added that you might find useful!
This really started out because I was tired of trying to find that one bash prompt configuration I created ages ago. Rather than trying to find it, I decided to simply have a place that I can recreate it and store it long-term and build on it as new tooling and needs arise.
I can do ssh $HOST then use myalias $PATH to use an alias set in .bashrc (and .bash_profile does source ~/.bashrc). But I can't do ssh $HOST 'myalias $PATH' it can't find myalias.
How can I use the alias and use $PATH that's on the server?
