I built a free CLI journaling tool for developers - just type "journal" and start writing

Every journaling app I've tried adds friction. Open the app, wait for sync, pick a template. By the time you're ready to write, the thought is gone.

journalot is a bash CLI that creates daily markdown files and auto-commits to git. Quick capture mode lets you log thoughts without opening an editor. Search finds old entries with context highlighting.

https://github.com/jtaylortech/journalot

Been using it daily for months now. Consistency comes from friction removal, not motivation.

https://i.redd.it/r7taegzq9ppg1.gif




https://redd.it/1rwp2y4
@r_bash

Can we redirect output to input using only redirection operation?

Edit (Solution): Let's first summarize the question so someone doesn't have to read the whole post.
I asked the question if the following syntax was possible.

    cmd1 <&1 # something here which involved a `cmd2` to feed the output of `cmd2` as input to `cmd1`
    # Yes, this the problem statement for which `|` (pipe) operator is the answer.
    # But I begged the question, if we can do it specifically in this syntax, just as a curiosity.

This is the answer.
I am leading you to the link so you can upvote the person who gave me this idea u/melkespreng.

Along the way, many who have told me, that's what pipe does or expect or some other solution, I appreciate you guys too.

Is this useful?
Edited: Yes, actually it is.
Since this method redirects in the same shell instead of creating a subshell like pipe, there are some specific cases of benefits.
Was it fun to know?
Yes.
For me atleast.

---
Edit: Just gonna write it here since I feel people don't understand my motive.

I know the solution I am telling has multiple solutions.
Piping, redirection of here strings and even a system tool.

The goal isn't to solve the problem of rm asking confirmation.
I am using that as an example.
The goal is to know if I can redirect the output to input in the way I mentioned below or something similar to that and not any of the above mentioned ways.

It's more exploration than a real problem.

---

I got this crazy idea that I want to try out and I have been able to figure it out.
I use rm -I instead of rm, basically set an alias in .bashrc.
Now, that leads rm always requiring confirmation when I have to delete something.

Now, the problem that I am going to state is solved for me in multiple ways but I want to know if I can solve it in this particular way somehow.
The problem is that I have to enter that "yes" message every time I have to delete something.
I can do yes | rm -r folder_name or printf "yes" | rm -r folder_name.
But I thought of what if we could redirect the output of a command to the input of another.

rm -r src <&1 # then something here

This obviously doesn't work because there is nothing that fd 1 i.e. stdout points to.

How can I put some command to replace the comment so that I can achieve what I said, redirecting the output of one command to the input of another?
I am asking for this specific way, the whole rm part is an example, not a problem.

PS: There is also this method which uses redirection but it is not using stdout technically, it is using here-strings.

    rm -r src <<< $(printf "yes")

https://redd.it/1rwbdjk
@r_bash

This bash program isn't closing the file descriptor

    printf "This is the first line\r\nThis is the second line\r\n" > "test.txt"
    : {fd}< "test.txt"
    read <&$fd-
    printf "$?; $REPLY\n"
    read <&$fd-
    printf "$?; $REPLY"

This program outputs:

    0; This is the first line
    0; This is the second line

The first read command should have closed the file descriptor but it seems like it doesn't. I don't understand this behaviour.

Edit: This is what the manual says.

> The redirection operator
>
> n<&digit-
> moves the file descriptor digit to file descriptor n, or the standard input (file descriptor 0) if n is not specified. digit is closed after being duplicated to n.

---
Edit (Solution): Took me a long time but here's the real use case of >&fd- and why its effect goes away after one command.

First, let's discuss why the effect goes away after one command. When we redirect, if the redirect was eternal, it would block a fd permanently. For example printf "hey" >&3 would lead to stdout permanently becoming a copy of fd 3 which isn't ideal at all. Therefore, bash automatically restores the state before the redirect after the command is complete.

Now this leads to the question, what is the point of >&fd- then?

Here's a code snippet to showcase that.

    # Run in one terminal
    mkfifo my_pipe
    cat my_pipe

    # Run in a separate terminal
    exec 3> my_pipe

    (
        echo "Worker is doing some fast work....
        sleep 100 > /dev/null & 

    ) >&3 &  # <--- HERE IS THE COPY (>&3)

    exec 3>&-

    echo "Main script finished."

Because we don't close the fd 3, sleep can potentially write to it which leads to cat waiting for 100 seconds before being complete. This leads to terminal 1 being stuck for 100 seconds.

Had we used >&3-, we would have made a move operation and hence there would be no open fd to write to for sleep which leads to cat exiting instantly.

---
This is the best from my research about this.

I could still be wrong about the exact order of operations that I explained for things. If I am, someone correct me.

https://redd.it/1rvfhao
@r_bash

Why is this pattern expansion not working?

## Code snippet:

printf "%q\n" "${MAPFILE@}"
printf "\n"

printf "%q\n" "${MAPFILE@/%$'\r'}"
printf "\n"

MAPFILE=("${MAPFILE@/%$'\r'}")
printf "%q\n" "${MAPFILE@}"
printf "\n"

I wrote this code, MAPFILE basically contains line copied from clipboard.
Each line ends with a carriage return \r hence.

## Output:

$'\r'
$'# This is the first line.\r'
$'# This is the second line.\r'

''
\#\ This\ is\ the\ first\ line.
\#\ This\ is\ the\ second\ line.

$'\r'
$'# This is the first line.\r'
$'# This is the second line.\r'

1) At first you can see that each line contains an ending \r.
2) Then if I just print the expansion output directly, there are no \r at the end of each line.
3) But then if I print after assignment, it has again changed.

I want to add before any one suggests this, we can change MAPFILE manually, it is not a constant.
I have changed this array in other places as well and the program works fine.

And mind you I have tried this method of removing a character for other characters such as \t and it works.
It is for some god forsaken reason, not working only when I try to remove \r.

ALSO: I can remove \r using a loop instead where I do the same pattern expansion but line by line.

I am using git bash on windows.
If anyone has any ideas about why this isn't working, it'd be a huge help.

https://redd.it/1rzjbue
@r_bash

Practice Examples

Ive been coding in python on windows for a while and consider it my main programming language, but Ive been intending to pick up another programming language for a while ( I was going to move to c / c++)

Tell me why, after installing Ubuntu on wsl to try it out

and my friend started teaching me some bash

is it literally so fun to write?

And like its kind of useful too because I can just make functions for navigating my terminal and new aliases...

Anyways Im looking for practice problems to go over, suitable for a beginner so I can keep learning, if you have any suggestions.

https://redd.it/1rzqod6
@r_bash

Made a script to send reels to the group chat
https://redd.it/1s00htk
@r_bash

I want to share my unit test lib for TUI apps

https://github.com/fissible/ptyunit

Most bash test frameworks only assert on stdout. That breaks down as soon as your script:

\- renders to /dev/tty

\- uses cursor movement / ANSI

\- handles arrow keys or interactive input

ptyunit runs your script inside a real pseudoterminal, sends keystrokes (UP, DOWN, ENTER, etc), and lets you assert against what a user would actually see.

out=$(python3 pty_run.py examples/confirm.sh RIGHT ENTER)

assert_contains "$out" "Cancelled"

I originally built this because I couldn’t reliably test a git diff TUI I was working on. Capturing /dev/tty output made it possible to catch layout and rendering issues.

It also doubles as a minimal assertion framework, so you can use it standalone instead of pulling in another dependency.

Would be curious if anyone else here is testing interactive bash tools, or if you’ve run into this gap before.

Install:

\- bpkg install fissible/ptyunit

\- brew tap fissible/tap && brew install ptyunit

Feedback welcome.

https://redd.it/1s048iz
@r_bash

...i know ...quite useless, but: ...why not watch /dev/video per bash script ? ;-P
https://redd.it/1s6gif6
@r_bash

How to improve bash script which is collecting data every 10 seconds

I wrote a script which is collecting data from solar inverter every 10 seconds for 5 minutes, it does some math and send data to [emoncms](https://github.com/emoncms/emoncms). It does work but is not optimal in term of CPU usage, it is running on SBC and consume roughly 80% of CPU time. My question is how can I initiate next data collection without checking script running time in a loop. Below is simplified script. I need to improve line 7.

#!/bin/bash
set -o pipefail
IFS=$''
samples="0"
nr="0"
while [ $SECONDS -lt 292 ]; do #5min-8s
if [[ (( $(( (samples - 1) * 10 + 10 )) == $SECONDS )) || (( 0 == $SECONDS )) ]]; then
((samples++))
timestart=$SECONDS
output="$(./inverter_poller --run-once)" # get data from inverter
timeend=$SECONDS
echo ${output} > /var/log/inverter.last
rs232time=$((timeend - timestart)) # usually it is 6-7 seconds
if (( rs232time < 17 )); # inverter is not responding if it is 17s or more
then
gridv=`echo ${output} | grep grid_voltage | tr -d " "_\",:[:alpha:]`
***more data extraction and math***
else
echo inverter not responding >> /var/log/inverter.last
fi
looptime=$((SECONDS - timestart))
echo "time": $looptime >> /var/log/inverter.last
fi
done
***boring data processing and sending to emoncms was here***

https://redd.it/1s6dsf2
@r_bash

Introducing: OneCommand

https://redd.it/1s689na
@r_bash

Function on .bashrc

Hello! I trying to add this function on my bashrc, but because of the quotes and single quotes, it's returning this error:
\-bash: .bashrc: line 142: unexpected EOF while looking for matching `''

\-bash: .bashrc: line 145: syntax error: unexpected end of file


The function is this one:
140 dwdb() {

141 local query="SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' ORDER BY TABLE_NAME;"

142 sqlcmd -S link -d table -U user -P 'password' -C -Q "$query"

143 }

https://redd.it/1s5emg1
@r_bash