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}" else PATH="${1}:${PATH}" fi PATH="${PATH#:}" PATH="${PATH%:}" fi }