Author Archives: admin

JavaScript Object References

Posted on by
Reply

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.

Ruby Array Methods Part 1

Posted on by
Reply

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.

Useful Shell Function pathmunge

Posted on by
Reply

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
}

 

Crypt Encryption Function Usage

Posted on by
Reply

crypto(3) is a function that provides basic criptography. It is at a so basic level that for serious work other than that of generating a shadowed password on the system, it is not recommended (as per a statement in its own man page).

The function is declared in the crypt.h file:

extern char *crypt (__const char *__key, __const char *__salt)

The input is a raw password string and a salt string, which is an additional value that provides a certain level of randomness to crypto’s hash generation process, so that there is not a single hash that may be produced for the same password, but several instead. If one provides a salt A, the output for the password X is Y whereas another salt B is passed, the output hash cannot be Y anymore, it will be some other hash Z.

I made a program in C which uses it, whose source code file I named cryptifier.c that has the following content:

#include <crypt.h>
#include <stdio.h>
#define _XOPEN_SOURCE
#include <unistd.h>
 
int main(int argc, char **argv) {
 
  const char *k = (const char *) argv[1];
  const char *s = (const char *) argv[2];
  char* r;
 
  printf("'%s' with salt '%s' generates '%s'\n", k, s, crypt(k, s));
 
  return 0;
 
}

The output of this function can be served as an input argument for useradd command’s -p option as described in a previous post.

IMPORTANT remark: when compiling a program that uses crypt.h now and having libc-6 it is necessary to specify -lcrypt (for libcrypt) on the gcc command line as libc-5 used to have crypt() in libc, whereas libc-6 has it in libcrypt (this is very old change, dated at least of 1998: source post).