Email or username:

Password:

Forgot your password?
42 posts total
Julia Evans

more weird terminal stuff: line editing

Show previous comments
fs111

@b0rk maybe mention that with set -o vi you get from weird emacs to weird vi keys

Jeff

@b0rk I did not know about rlwrap. (I did know about readline, this image is great, and "readline but worse" is totally reasonable commentary)

@ed1conf `rlwrap ed` is basically quick'n'dirty en/ex enhancements for `ed(1)`. I'm probably still going to just use vanilla ed(1), but having the arrow keys work was interesting.

David Hashe

@b0rk My personal taxonomy puts prompt_toolkit (the custom lib used by ipython) at the same level as readline and libedit.

It's a reusable component, and it definitely aims to be the Python version of readline. I've used it to add line editing to a personal project and I quite like it.

Julia Evans

Yesterday a program made my terminal’s cursor disappear! I was really surprised because programs so rarely mess up my terminal these days. (fish prevents almost all problems like this)

the problem was that it printed out "\033[?25l" to make the cursor invisible without printing out a corresponding "\033[?25h” to make it visible again

like most "my terminal is broken" problems you can fix this by running `reset` but it was VERY disorienting until I realized what had happened

screenshots:

Show previous comments
Simon Tatham

@b0rk it is a bit annoying that there's nothing you can sensibly do before printing a shell prompt that resets _everything_.

The 'reset' program sends ESC c, which resets the terminal completely to its power-on state, including clearing the screen. But you don't want to clear the screen before every shell prompt. You'd like a sequence that does all of ESC c _except_ that!

So instead the shell has to think of every individual setting that might need to be reset, and likely forget one :-(

João S. O. Bueno

@b0rk i still remember the day I first met "reset". If there were an oscar nomination for cli utilities, I'd certainly name it.

Julia Evans

spent some time today working on this diagram of how the ASCII control characters work in unix

there are a lot of mistakes/missing nuance but I think it's really interesting how little structure there is. Special codes (like `3` for SIGINT) that are handled by the OS are mixed with just regular keypresses (like `13` for "enter”) which are mixed with codes that are handled by the application (like `1` for Ctrl-A in readline)

(not looking for history lessons right now)

Show previous comments
Charlesflorian

@b0rk This may be a silly question, but how do some of these key combinations work with different keyboard layouts? For example, on a Swedish (mac) layout, the @-symbol is alt-gr-2; Do you type ctrl-alt-gr-2 to get the null character?

Ajaya Agrawalla

@b0rk You are doing god's work. Thank you.

Merc

@b0rk For me, CTRL-U is "oops I messed up typing my password let me try again". Where CTRL-K is "kill from cursor to end of line", CTRL-U is "kill entire line".

This is really useful for password entry fields where you don't get stars or any other indication you've typed anything, so you don't know where your cursor is.

But, with anything involving shells or terminals, it's complicated. Apparently BASH and some other things think CTRL-U is "kill from cursor to beginning of line" and many other shells including ZSH think it's "kill entire line". I don't actually know what interpretation is in charge in a password entry field... but I still mash CTRL-U when I know I mistyped something.

@b0rk For me, CTRL-U is "oops I messed up typing my password let me try again". Where CTRL-K is "kill from cursor to end of line", CTRL-U is "kill entire line".

This is really useful for password entry fields where you don't get stars or any other indication you've typed anything, so you don't know where your cursor is.

Show previous comments
Bill Mill

@b0rk I recently implemented a db struct based on the sqlite article you referenced, and this is how it came out: gist.github.com/llimllib/2d03a

I'd love to see how other people have implemented it!

Chris Simpson

@b0rk thanks, I'm using mux routing but my handlers can be a bit complex so this will help simplify them

mangesh

@b0rk Hi Julia, I was curious to know how you built the categories thing in your blog page. Is the website open sourced, I'd like to have a peak and implement it in my own as well :p

Julia Evans

I really love diffdiff.net for quickly looking at diffs -- it does a great job of highlighting diffs inside a single line

used it yesterday to debug a networking issue by diffing two tcpdump outputs and it was SO helpful, it made it immediately obvious that the MSS was different between the two connections

(the screenshot isn't the actual bug, just a diff of two tcpdump outputs)

Show previous comments
VZ

@b0rk git-diff can be used with the files outside of the repository and you probably already know about its --color-words option.

Otherwise there's github.com/ymattw/ydiff and is multiple forks called cdiff.

bew :nixos:​:neovim:

@b0rk `git diff --no-index before after` can be nice too, if you have configured a nice diff pager like delta!

Julia Evans

i quit my job just over 5 years ago to explain computer things (jvns.ca/blog/2019/09/13/a-year). I had no idea if I would like being my own boss but ultimately it's been really cool and I'm happy to have this weird job writing zines about computers.

("I’m not planning to hire employees or anything” turned out to not be an accurate prediction, now I work with 2 part-time employees who I don't know how I would manage without)

Show previous comments
Ron Jeffries

@b0rk
Watching from afar, I admire you for trying it, and admire you more for the success you are finding. Well done!

Julia Evans

someone asked me recently how long it took me to get used to the rhythm of working for myself and I said “uh, maybe 3 years?”. I thought working for myself would be hard to adjust to and it was, but I'm happy I did it anyway

Julia Evans

the debugging manifesto poster I've been talking about is finally available for sale! You can get it here for $20 US + shipping: store.wizardzines.com/products

it was redesigned and riso printed by Inner Loop Press and I'm SO delighted with how it turned out (innerloop.press/)

Show previous comments
Steve's Place

@b0rk I was sitting next to another programmer who, after much trying, threw his hands up and exclaimed, "Well, it won't work," then a half-hour later had it working. A puree of 2 and 4.

Dan Kim

@b0rk Love this and purchased! Literally just went through a problematic debug yesterday and thought of this.

Julia Evans

it's been really fun to see zines in libraries -- the folks from Swarthmore (swarthmore.edu/news-events/diy) sent me this photo of How Git Works in their zine library

Show previous comments
akahn

@b0rk I also came to the Emacs strokes late, as a Vim user. one great thing about learning them is that they work in a lot of macOS UIs too. In particular ctrl-p/ctrl-n

Simon Racz

@b0rk thanks for the post. I learned new things from it. I love your approach to learning.

I did a similar investigation some time ago. In the end I made a game in the terminal to make it more interesting. :)

youtu.be/WvSOSyi5lWY

noone

@b0rk CTL-[ is still how I type ESCAPE, due to too many years of odd keyboard layouts.

Julia Evans

people have been asking us for printed posters FOREVER but I've always been unsatisfied with just printing out the existing PDFs of our posters -- they didn't feel quite polished enough to me.

So I collaborated with the incredible Tanya at Inner Loop Press (check out their website! it's so good! innerloop.press/) to make this delightful risograph printed Debugging Manifesto poster. I love the design she came with SO MUCH.

they're not available just yet but they'll be on the store soon!

people have been asking us for printed posters FOREVER but I've always been unsatisfied with just printing out the existing PDFs of our posters -- they didn't feel quite polished enough to me.

So I collaborated with the incredible Tanya at Inner Loop Press (check out their website! it's so good! innerloop.press/) to make this delightful risograph printed Debugging Manifesto poster. I love the design she came with SO MUCH.

Show previous comments
don

@b0rk The color scheme might clash with the rest of the room, but I love the idea.

Jigme Datse

@b0rk I was wondering if this was Risograph, or something similar, because it feels so perfect for that. Awesome.

ck

@b0rk For me personally, this is missing step 0: Take a shower, take a walk, have a cup of tea, take a nap.
Can be combined in any subset or order, as long as it gets you away from the machine for ten minutes.

Julia Evans

I know $12 USD is a lot of money for some people, so to celebrate 1000+ sales (!!!), I'm giving away 1000 PDF copies of How Git Works (honour system: only if $12 is a lot of money for you!)

Here's the link, enter code BUYONEGIVEONE at checkout to get a free copy wizardzines.com/zines/git/

(it'll ask you for a billing address but you can enter a fake address if you'd prefer)

Julia Evans

I think a lot about how

1. a lot of command line UIs are kind of bad
2. building better UIs is great
3. but taking the time to get comfortable with a bad UI has often really paid off for me
4. I'll often keep using an older tool with a worse UI because it's more stable, or more actively maintained, or has more features, or has more examples available, or my friends use it
5. it's still important to acknowledge that the UI is in fact bad even if I'm pretty comfortable with it now

Julia Evans

anyway i've been trying to summarize my relationship with git (which I love) in a single panel and this is where I landed today

Show previous comments
Stu

@b0rk Oh that is awesome. I've definitely checked things in to the wrong branch. I just pulled up the Git Bash terminal (I'm limited with what I can access, on $work machine) and it includes the (branch) thing!

Julia Evans

poll: do you use git on the command line or in a GUI?

(you can pick more than one option if it’s a mix of both, sorry magit users I didn't have space for you in this poll)

Anonymous poll

Poll

command line, regularly
1,832
0%
GUI, regularly
666
0%
command line, occasionally
290
0%
GUI, occasionally
375
0%
0 people voted.
Voting ended 1 March at 13:22.
Show previous comments
Chris Siebenmann

@b0rk I voted command line + GUI, with the latter being for my Magit usage (and I guess Github blame view). I use the command line for pull, rebase, log, diff, and many blame operations. I use Magit for committing things, especially selective commits, and thus for checking diffs before I commit and so on. (And some use of git-timemachine in Emacs to move back and forth through the history of a file to track things.)

But my git use is odd since I track and monitor a lot of upstream repos.

×

@b0rk I have used @fork_dev for the last 5 years or so and I can't be any happier

Felix Neumann

@b0rk

I work in IntelliJ, and it’s Git UI is so good (or I spent enough time to get used to it’s rough edges, too), that I feel much less productive on the CLI.

I wonder why IntelliJ users still use the git CLI, esp. for staging, writing commit messages, diffs and git blame.

But also branch operations and git log are good enough or even really good, depending on the use case. I totally recommend the interactive rebase UI!

Julia Evans

i really appreciate that we can have great conversations here on mastodon if I’m extremely careful about every single thing I post and often include disclaimers (“please don’t explain rebase to me”) to avoid repetitive annoying replies that I can predict

but I still feel like I need to be SO much more careful about my posts than I was on Twitter and I wish it wasn’t like that

Show previous comments
datarama

@b0rk FWIW I like reading your posts. At the moment, I really need reading about tech stuff from the perspectives of people who *aren't* total assholes.

For myself I gave up on writing anything substantial online for many reasons, one of which is that I don't have the psychological constitution for potential large audiences (and hence, maintaining a "real" social media presence). I wish it wasn't like this, and I hope doing what you do doesn't burn you out.

Uckermark MacGyver :nonazi:

@b0rk I feel you. Try to ignore this stuff if you can. You're doing important work here 🙏

Baldur Bjarnason

@b0rk This has been my experience as well. And I’m a middle-aged white dude. I imagine it’s even worse for people in other demographics

Show previous comments
arky

@b0rk Thank you! This is so much clearer than any of the many other explanations I've tried to read before now.

And I hadn't even heard of squash: I was just trying to understand the difference between merge and rebase... (Yes, I put off learning git about ten years longer than I should've.)

Catboy Cody :v_cat:​:v_bott:​:v_mlm::v_ace:

@b0rk There's a fourth option though: The "student has their first merge conflict, panics and tries to sort it out themself instead of asking for help"-option.

- Checked in conflict-markers: ☑️​
- Checked in backup and temporary checked-out files for git merge-tool: ☑️
- Merge commit that only contained the changes of only one branch ("ours"-strategy wasn't intended): ☑️
- Merge commit that contained the content of a unrelated third branch, but non of the changes of the two merged branches: ☑️

Neil Kandalgaonkar

@b0rk Perfect. What an elegant way to represent commit graphs. And thank you for articulating my dread of merge graphs

A squash + rebase looks almost ideal to me. I'm going to do that more often.

The negatives of squash + rebase look minor to me though. Is a 3000-line PR any better with the other options?

Show previous comments
Massimo Lauria

@b0rk so every time you touch a file, there is a whole new copy in a blob? 😨😱

DELETED

@b0rk this is making me want to finally sit down and work through shop.jcoglan.com/building-git/ where you build a simplified working git clone

invisiblethreat

@b0rk great content! (As always). I recently found pre-commit.com/ as a really useful tool for distributing coding standards inside a git repo. A bit different than what your current content, but one of worst sort of merge conflicts on teams is formatters gone rogue, IMO.

Show previous comments
Kim Gräsman

@b0rk Thanks, I liked that! This post woke something in me re the discussion on rebase vs merge the other day. I think I prefer rebase/linear history because it maps very well to a sequence of patch files that could be copied around and applied independent of git itself. Not sure why that feels so "pure" to me, but it does.

Richard Levitte

@b0rk
Really nice blog, and yeah, confirmed, there's a stark difference between the mental model (I'm one of the "all of the above" folks) and the actual technical model.

Speaking of this, before git, I worked a lot with monotone, which has quite a lot of similarities to git... however, storage wasn't one of them. Monotone stored commits as diffs, so there were situations where they had to be replayed en masse. That could be quite a performance hit...

Show previous comments
Julia Evans

a bunch of folks have mentioned that they use rerere to avoid solving the same merge conflict a million times during a rebase. If you use it, do you find it works well? are there any downsides to using it?

Aleksander

@b0rk If rebase is going badly I sometimes do `git reset main` instead and craft the commits I need. A lot of the times it’s a single commit anyway!

Romain :verified:

@b0rk I literally told my 2 juniors today to stop force-pushing rebased versions of their PRs to GitHub if there are already comments on some of the old commits, and to instead merge over them... turns out a lot of nice GitHub stuff breaks when you rewrite history

Go Up