If you do much Linux shell scripting, you’ve probably encountered sed — the stream editor — in an example. Maybe you’ve even used it yourself. If all you want to do is substitute text, it is easy and efficient. But if you try to do really elaborate editing, it is often difficult to get things right. The syntax is cryptic and the documentation is lacking. But thanks to [SoptikHa2] you can now debug sed scripts with a text-based GUI debugger. Seriously.
According to the author, the program has several notable features:
- Preview variable values, both of them!
- See how will a substitute command affect pattern space before it runs
- Step through
sedscript – both forward and backward! - Place breakpoints and examine program state
- Hot reload and see what changes as you edit source code
- Its name is a palindrome
There’s only one word for that last feature: wow.
Honestly, we are more likely to reach for awk or Perl if we have heavy lifting, but we know that’s a lot of overhead for many tasks. Being able to see what’s really happening inside sed might make us a little less reticent to do things with sed in the future.
The code is in Rust and it uses a debugging interface that has always been in sed. Who knew? If you want more details, the author has a blog post about the program that goes into a bit of detail. The built-in debugging interface gives you a lot of internal state information but omits one thing: the command that is executing. So the debugger has to simulate part of sed to keep track of what statement is executing.
If you need debugging on the rest of your script, relax. Or, try avoiding the bugs in the first place.
seds regular expressions and its syntax are really atrocious. Escape this, but not that, capture groups not working, etc. pp. Maybe the tool helps, but I’d still not go anywhere near sed when I don’t have to…
Sed is nice for doing quick, basic manipulations but usually for anything more than doing word replacing or a really basic regex I am gonna reach for awk.
If you have a repetitive job, it’s worth testing sed vs awk. Sed’s usually faster. It can get cryptic very fast, but it is also fast.
I’ll be the first to drop the old chestnut:
1) you have a problem
2) you solve it with a regex
3) now you have two problems
sedsed (https://aurelio.net/projects/sedsed/) already exists for quite some time.
Thanks for posting this. I had not seen it before.
It can be difficult to determine whether a problem can be solved with regular expressions and you could waste an hour easily trying to find a combination that works. AWK in the meantime is trivially turing complete, it will work, it’s just a matter of effort.
“a text-based GUI debugger.”
isn’t that an oxymoron? I mean TUI & CUI do exist or are they so obscure that we’re dealing with GUI inception into text-only consols now? ;-)
curses, if it wasn’t for those deseddling kids…
probably true, but what does “deseddling” mean?
DuckDuckGo has only one hit[1] – your comment ;-)
unsettling?
[1] https://duckduckgo.com/?q=deseddling
Well desed is the tool, used deseddling to mean generically doing something with it, either writing it, or about it, or using it. Just to ryhme with meddling, from the Scooby Doo quote, So I could use “curses” referring to the textmode library which enables TUI on Vax/BSD and as ncurses on Linux. My jokes aren’t nearly as funny when I have to explain them.
I got it the first time! It was funny! Thanks for the SED and SCOOBY hybrid humor. :)
Well I have heard the term TUI before I don’t think it’s instantly recognizable for many people. Where is I think almost everyone can intuit what a text GUI is.
One of the funniest I’ve seen was one of the Microsoft centric IT guys in the department looking over my shoulder while I was writing a busybox script in ash and using sed to extract and parse serial GPS data. He wanted to know the command line arguments for sed. I handed him the 394 page ‘sed and awk’ book.