Run the following command (Start->Run or ctrl + r), assuming your Dropbox is installed at your profile directory (%userprofile%), if not alter it properly:
regedit /e "%userprofile%\Dropbox\putty.reg" HKEY_CURRENT_USER\Software\SimonTatham
With Dropbox installed on the user’s profile directory you just run this command in the most up to date machine and later on you get your entire PuTTY setup when logged in your other hosts.
If you have poorly written software which corrupts your file system e.g. during its installation, you probably face the problem that once the error occurs, the filesystem will lock for writing, and then your installation suddenly dies, hopeless.
Well, in the case that you want to force it to continue, even after (it) having broken your file system, you can, if it is in the EXT family (EXT2, EXT3 filesystems). The command is (as root) this:
tune2fs -e continue device
device is the one device this option is going to be applied.
Then, after the next reboot, e2fsck (file system check) will check the error, anyway, so you are “safe”. I had two situations installing poorly written software (I hope only the installer is poor in quality), and it helped going on until the end. One of them uses file system intensively and did not present any errors during production execution.
This is analogous to the mount command’s option errors (mount -o errors=continue). Or it can also be one of the options field’s values, in the fstab file e.g. “defaults,errors=continue“.
As Sinatra, Padrino route definitions accept regex when used as the :map option’s value in named aliases.
A standard named alias (‘thisroute’) mapped to some url with a code parameter embedded in the URL:
# For URLs like /someslug/anytext get :thisroute, :map => '/someslug/:code' do # code param available as params[:code] end
Accessing it as a block parameter, like in Sinatra, is also possible:
# For URLs like /someslug/anytext get :thisroute, :map => '/someslug/:code' do |code| # code param available as request scope variable named code end
And the killer one, if we want to enforce a pattern to the parameter, we capture it in a regex (suppose we only want to allow digits for that parameter, one or more), like this:
# For URLs with digits in param., only e.g. /someslug/123 get :thisroute, :map => %r|/someslug/([d]+)| do |code| # code made of digits captured by regex available as code var. end
Behold! And YES!! The first capture (text matched by the regex portion inside the parenthesis – the regex syntax element which delimits a capturing group) is available as the first block parameter, super conviniently! Now go enjoy it, and boost up your Padrino application routing!
What components were chosen by the person who created some padrino project? Go (cd command) to its root path and then:
$ cat .components --- :orm: datamapper :test: rspec :mock: mocha :script: jquery :renderer: slim :stylesheet: scss
For ORM datamapper was chosen. For the renderer, slim. For the stylesheets, scss (new sass). Etc.
To export the HEAD of your current branch (the one with an asterisk before it, on ‘git branch’ command’s output) in your git repository, do the following:
git archive HEAD | (cd ~/somedir_where_to_put_it/ && tar -xvf -)
Provided that ~/somedir_where_to_put_it already exists, otherwise, mkdir it.
Instead of HEAD you could use any revision’s hash number and then the codebase as it was in that commit would then be exported. To obtain such hash number read git log’s output.
Note: tar -xvf - is the command that consumes the subshell’s (delimited by the parenthesis after the pipe) input. It extracts a tar content from stdin (represented by the minus symbol at the end of the command, before closing the parenthesis) which was provided by git archive, thus, it is possible to conclude that git archive provides in its stdout a.k.a. standard output stream, the contents of the codebase at the given revision, in tar archive format.
Objects are always referenced in JavaScript. When you put such a reference as the right value of an assignment expression, what is assigned to the left value element is this reference. An object is never referenced another way in this programming language.
Let us see a simple example with empty object literals being assigned to multiple variables:
var a = {}, b = {}, c = {};
Each variable has a reference to a distinct empty object.
Now:
a = b = c = {};
All three variables have the same reference, to the same empty object.
Simple enough.
Check this code out:
1.9.3-p0 :001 > a = [1, 2, 3] => [1, 2, 3] 1.9.3-p0 :002 > a.delete(2) => 2 1.9.3-p0 :003 > a => [1, 3] 1.9.3-p0 :004 > a[3] = 4 => 4 1.9.3-p0 :005 > a => [1, 3, nil, 4] 1.9.3-p0 :006 > a.compact => [1, 3, 4] 1.9.3-p0 :007 > a => [1, 3, nil, 4] 1.9.3-p0 :008 > a.compact! => [1, 3, 4] 1.9.3-p0 :009 > a => [1, 3, 4]
The delete method removes the object instance passed to it from the array, and takes out this position i.e. moving all the next items one position to the left (decrementing their indices by one). The number 2 there is a reference to the Fixnum instance whose value is two. Fixnum is one of the special exceptions in Ruby, in that each literal is ALWAYS the reference to that same instance, with that integer value.
The compact method takes out positions that are / have nil in them, moving the non nil elements one position to the left. compact! as with most methods in Ruby, by convention on the usage of the exclamation point as a part of the method name, alters the method receiver object which in this example is the array instance referenced by the identifier ‘a’. The version without the exclamation mark does not alter the receiver, it just returns a new array leaving the receiver intact. The example code shows the results of these operations as a proof.
When I wrote a function that updated the PATH environment variable to include a new directory path in its set of values I had named it “addtopath”, and “addtopathhigh” when prepending such directory. I was tweaking the /etc/profile file in Red Hat Enterprise Linux 5.3 when I saw this pathmunge function. It does the same:
pathmunge () { if ! echo $PATH | /bin/egrep -q "(^|:)$1($|:)" ; then if [ "$2" = "after" ] ; then PATH=$PATH:$1 else PATH=$1:$PATH fi fi }
The difference, is that it both prepends and appends the PATH variable with the given argument ($1). The second argument controls whether it is an append operation when it is passed the value “after”, otherwise, it just prepends the given path to PATH’s value (analogous to the addtopathhigh function, which prepends the directory to the value and thus makes the added path with HIGHer priority in the search path, that was the reason why I named it that way).
In order to maintain it standard with RHEL I decided to adopt this function. Same name. But I improved it. The new definition expands the variables with curly braces, and after the pre/append it also sanitizes it by cleaning any preceding or trailing semi-colons for the basic case when the PATH variable had an empty value prior to the “munging”.
Here it is:
pathmunge () { if ! echo "${PATH}" | /bin/egrep -q "(^|:)${1}($|:)" ; then if [ "$2" = "after" ] ; then PATH="${PATH}:${1}" PATH="${PATH#:}" else PATH="${1}:${PATH}" PATH="${PATH%:}" fi fi }