Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Write Some Bad Ruby

hashrocket.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Let's Write Some Bad Ruby

#31

Post by lisivka »

ricardobeat wrote: post #21

I (frontend/javascript developer by trade) wholeheartedly recommend learning the standard unix tools - bash, sed, grep, awk, xargs - for these tasks. While the syntax is daunting at first, and escaping will be an eternal problem, eventually it starts making sense and you'll be able to do anything in seconds. The work in the post becomes trivial: mv app/views/foo/**/* app/views/ sed -i 's/\([a-z]*\)foo_\([a-z]*\)path/…

It is better to learn perl instead of sed/awk. It is much more powerful and cleaner than both of them:

  perl -pi -e 's{(.*?)foo_(.*?)path}{$1$2path}' app/views/*/*

Re: Let's Write Some Bad Ruby

#32

Post by anon4 »

DIVx0 wrote: post #2

I have a scratch folder full of stuff like this written in whatever scripting language is closest at hand, ruby, perl, python, etc. I'd wager most people here would have something similar. I wonder if it would be an interesting project to comb though it all and see if any useful tools could be extracted. Probably not, like the code in this blog most of my one-offs are unashamedly terrible.

I have this dumb C program that scans a folder of .mp3 files and fixes their id3tags from shift-jis encoding to utf-8. Shift-jis isn't officially supported for mp3s, but Japanese Windows uses it as the default encoding for non-UCS2 strings, so when you display a tag that's "latin-1 encoded" on a Japanese locale, it shows up fine, but shows up as gibberish on everything else - https://github.com/moshev/tagfixr

Re: Let's Write Some Bad Ruby

#33

Post by junke »

lisivka wrote: post #30
junke wrote: post #28

Earlier quoted context omitted.

I don't do this anymore. I learnt how to use bash, sed, grep, awk, netcat, socat, and as a user, I work in terminals. I accumulated a lot of scripts, to the point where they were the first set of tools I would reach. But it becomes a self-renforcing loop: the more you rely on this toolbox, the more problems you create that are best solved with the same tools and the particular mindset they promote. But for work-relat…

Globing works fine with spaces, but you need to quote variables, e.g. $file -> "$file", to avoid parsing of their content by bash. See Bash-FAQ for details. Problem with shell is that you need to solve same problems again and again. This is why I wrote "bash-modules" script ( https://github.com/vlisivka/bash-modules ), which allows to write module with common code and then just do ". import.sh module" from script or…

Yep, right, I forgot: globs are expanded after IFS word splitting. I retract my comment about globbing not working with spaces, and instead I'll add this one:

    app/views/foo/**/*
If the above does not match any file and you are not lucky enough to use nullglob, your script iterates once in the loop with the value bound to the pattern itself! (I learnt this from http://www.dwheeler.com/essays/filenames-in-shell.html, which is quite informative).

I honestly commend you for writing a Bash library to solve problems people can have with bash ("Fight fire with fire"). I looked for other libraries, by curiosity, and unsurprisingly there are a lot of them. See this list: http://elinux.org/Scriptin.

For example, http://marcomaggi.github.io/docs/mbfl.html has a function to split a pathname into different components, which definition is here: https://github.com/marcomaggi/mbfl/blob/master/src/modules/f....

I am not criticizing, just stating that it looks painful to write and that I don't wont to endure this.

Re: Let's Write Some Bad Ruby

#34

Post by bad_login »

Before i thought mastering regexp were a must to have in a day to day programmer job to quickly modify data with different syntax.

Now i am still convinced that regexp are still usefull but you will not get it right for the first try due to syntax corner case. The best solution in my opinion is to have easy to use parsers including one for your main programming language.

Actually i emacs with its macro feature (not elisp) + racket with regexp (didn't mention earlier but having a strong repl for this kind of incremental script is also a must to have) and sometimes parsers.

Re: Let's Write Some Bad Ruby

#35

Post by lisivka »

junke wrote: post #33
lisivka wrote: post #30

Earlier quoted context omitted.

Globing works fine with spaces, but you need to quote variables, e.g. $file -> "$file", to avoid parsing of their content by bash. See Bash-FAQ for details. Problem with shell is that you need to solve same problems again and again. This is why I wrote "bash-modules" script ( https://github.com/vlisivka/bash-modules ), which allows to write module with common code and then just do ". import.sh module" from script or…

Yep, right, I forgot: globs are expanded after IFS word splitting. I retract my comment about globbing not working with spaces, and instead I'll add this one: app/views/foo/**/* If the above does not match any file and you are not lucky enough to use nullglob, your script iterates once in the loop with the value bound to the pattern itself! (I learnt this from http://www.dwheeler.com/essays/filenames-in-shell.html ,…

Many CLI commands are working differently with and without arguments, e.g. "cat foo" (read from file) and "cat" (read from stdin), so "nullglob" is dangerous option. Just check your data instead. It is bad idea to run sed on /dev/sda, anyway.

My "bash-modules" project is wrapper around libraries. It solves common problem: how to import library (where it is located, /lib, /usr/share, /usr/lib, /etc, /usr/local, /usr/local/share, /usr/local/share, /opt/..., /home/..., etc.). Instead of path hell, you can just type ". import.sh ..." in CLI, script, or library. It also should solve problem with versions in common way (via symlinks from exact version to general name, e.g. args-1.0.2.sh -> args.sh), but I have no free time to add that.

Re: Let's Write Some Bad Ruby

#37

Post by smithkl42 »

muzmath wrote: post #27
smithkl42 wrote: post #23

I don't know that I could have asked for a better explanation as to why my preferred environment is C#, Visual Studio and Resharper.

I thought the explanation is that you work for a .NET shop?

Sort of. I've been the CTO and first tech employee at my last four gigs, which means that they're .NET shops because I wanted them to be .NET shops. Correlation and causation :-).
Post reply on HN