Re: [dev] Re: a suckless hex editor

Neither vi, vim or xxd are suckless. Anyone has tried ired/vired? > On 14 Nov 2015, at 06:15, Random832 wrote: > > Greg Reagle writes: >> I agree that it is a "poor man's" hex editor. I am having fun with it, even >> if >> it is a toy. I don't have the desire to write a sophisticated hex

Re: [dev] a suckless hex editor

No. Not just this. Rtfm... Rm -f is needed if you dont want a prompt to remove that file in case of custpm umask or a race condition with another script happens. > On 14 Nov 2015, at 03:40, Greg Reagle wrote: > >> On Fri, Nov 13, 2015 at 09:42:11PM +0100, pancake wrote: >> Use rm -f > > I

[dev] Re: a suckless hex editor

Greg Reagle writes: > I agree that it is a "poor man's" hex editor. I am having fun with it, even > if > it is a toy. I don't have the desire to write a sophisticated hex editor > (besides they already exist). > > I like that the small shell script can turn any editor into a hex editor. > BTW

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 07:54:07PM +0100, Nico Golde wrote: > I'm sorry to be blunt, but this is not a suckless hex editor, but a poor mans > hex editor that's barely useful for any real work in my opinion. I mean it > may > work fine for changing a single byte here or there and look at dumps, bu

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 08:51:24PM +, Connor Lane Smith wrote: > On 13 November 2015 at 20:42, pancake wrote: > > Also, echo is a buildtin, so dont use absolute path for it > > My guess is the path was added because the builtin echo may not > support the -e flag. But that's because it's non-s

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 09:42:11PM +0100, pancake wrote: > Use rm -f I don't get it. Is this a Unixy geeky way of saying you don't like it?

Re: [dev] a suckless hex editor

Hi, * Greg Reagle [2015-11-13 18:33]: > What do you think? I was afraid to overwrite the infile so I make the user > specify an outfile. Maybe if I did better error checking it would be okay > to overwrite? I'm sorry to be blunt, but this is not a suckless hex editor, but a poor mans hex editor

Re: [dev] a suckless hex editor

On 13 November 2015 at 20:42, pancake wrote: > Also, echo is a buildtin, so dont use absolute path for it My guess is the path was added because the builtin echo may not support the -e flag. But that's because it's non-standard -- as are all echo flags, really -- and as Dimitris says printf shoul

Re: [dev] a suckless hex editor

Also, echo is a buildtin, so dont use absolute path for it > On 13 Nov 2015, at 20:54, Dimitris Papastamos wrote: > >> On Fri, Nov 13, 2015 at 02:52:17PM -0500, Greg Reagle wrote: >> Okay then. It no longer depends on xxd. It depends on od for the hex dump >> (works with both GNU od and sbas

Re: [dev] a suckless hex editor

Use rm -f > On 13 Nov 2015, at 20:54, Dimitris Papastamos wrote: > >> On Fri, Nov 13, 2015 at 02:52:17PM -0500, Greg Reagle wrote: >> Okay then. It no longer depends on xxd. It depends on od for the hex dump >> (works with both GNU od and sbase od) and echo, awk, tr, cut for the reverse >> h

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 02:52:17PM -0500, Greg Reagle wrote: > Okay then. It no longer depends on xxd. It depends on od for the hex dump > (works with both GNU od and sbase od) and echo, awk, tr, cut for the reverse > hex dump. > #!/bin/sh > [ -z "$1" -o -z "$2" ] && { echo "$0 infile outfile";

Re: [dev] a suckless hex editor

Okay then. It no longer depends on xxd. It depends on od for the hex dump (works with both GNU od and sbase od) and echo, awk, tr, cut for the reverse hex dump. #!/bin/sh [ -z "$1" -o -z "$2" ] && { echo "$0 infile outfile"; exit 1; } [ -z "$EDITOR" ] && { echo "\$EDITOR must be defined"; exit

[dev] [slcon2] Videos are now online!

Good evening fellow hackers, videos of the slcon2 talks are now online[0] in the webm format. Have fun! Cheers FRIGN [0]: http://suckless.org/conference/ -- FRIGN

Re: [dev] a suckless hex editor

Check ired. From the radare github repo > On 13 Nov 2015, at 19:50, Matthew of Boswell > wrote: > > On Fri, 13 Nov 2015 11:28:36 -0500 > Greg Reagle wrote: > >> What do you think? > > I personally wouldn't use it over hexer, but it's an interesting idea. > > Pros: > - very minimal; great

[dev] out-of-tree patches

Hi, Would it make sense to keep latest out-of-tree patches in a git repo? It's not a lot of work to keep them up to date, but on the other hand I guess many people do the same thing over and over again. lieven

Re: [dev] a suckless hex editor

On Fri, 13 Nov 2015 11:28:36 -0500 Greg Reagle wrote: > What do you think? I personally wouldn't use it over hexer, but it's an interesting idea. Pros: - very minimal; great for embedded (assuming no dependence on vim) Cons: - can't edit the ascii values on the right; everything is parsed from

Re: [dev] a suckless hex editor

On 11/13/2015 12:17 PM, Louis Santillan wrote: tr, bc & awk? Very cool. I'll see what I can do.

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 8:55 AM, Greg Reagle wrote: > On 11/13/2015 11:45 AM, Alex Pilon wrote: >> >> xxd's provided by vim. As convenient as it is, should a "suckless hex >> editor" really depend on that? It should be the user's choice or not to >> install vim, regardless of anybody's feeling's o

Re: [dev] a suckless hex editor

On 11/13/2015 11:45 AM, Alex Pilon wrote: xxd's provided by vim. As convenient as it is, should a "suckless hex editor" really depend on that? It should be the user's choice or not to install vim, regardless of anybody's feeling's on this list *either* way. Is there another tool that can do a r

Re: [dev] a suckless hex editor

On Fri, Nov 13, 2015 at 11:28:36AM -0500, Greg Reagle wrote: > What do you think? > > […] > > #!/bin/sh > > […] > dump="xxd -g1" > dedump="xxd -r" xxd's provided by vim. As convenient as it is, should a "suckless hex editor" really depend on that? It should be the user's choice or not to install v

Re: [dev] a suckless hex editor

Improved a little. Is it appropriate for inclusion in sbase? #!/bin/sh dump="xxd -g1" dedump="xxd -r" [ -z "$1" -o -z "$2" ] && { echo "$0 infile outfile"; exit 1; } [ -z "$EDITOR" ] && { echo "\$EDITOR must be defined"; exit 1; } tmpfile=$(mktemp) || exit 1 infile="$1" outfile="$2" $dump "$in

[dev] a suckless hex editor

What do you think? I was afraid to overwrite the infile so I make the user specify an outfile. Maybe if I did better error checking it would be okay to overwrite? The user can choose to overwrite by specifying the same file for both infile and outfile. #!/bin/sh [ -z "$1" -o -z "$2" ] &&