Back when I first started its development in 2007, there was no official, versioned API and it’s managed to continue working this entire time. Clearly, Twitter decided that with v1.0 of the API deprecated, that anything using older calls than that would no longer need to be supported. So, I’ve updated to the v1.0 API calls and all is working again… for now (more on that in a sec).

Go download v0.7.2 now (the source code is also on GitHub), or you can just change the following line in your HTML:

<script type="text/javascript" src="http://www.twitter.com/statuses/user_timeline/morgant.json?skip_user=true&callback=makkintosshu.twitterStatuses.twitterCallback"></script>

To the following (replacing “morgant” with the appropriate Twitter username for your use, of course):

<script type="text/javascript" src="http://api.twitter.com/1/statuses/user_timeline.json?screen_name=morgant&callback=makkintosshu.twitterStatuses.twitterCallback"></script>

A Few Words on the Future

Now, v0.7.2 of my Twitter Statuses JavaScript Badge only brings us up to v1.0 of the Twitter API which is now deprecated and will be discontinued in roughly six months. Why not go straight to v1.1 of the Twitter API? Well, there are two major changes in v1.1 that would have a major impact on the JavaScript badge: requiring OAuth for all API requests and the display guidelines will become display requirements.

The latter, requiring the JavaScript badge’s display to conform to the specific display requirements, would require some minor CSS changes and is not too big a deal. That said, since the primary goal of the JavaScript badge is to allow customization of the styling, esp. integrating with a site’s theme, it could not enforce that only certain styling rules would be modifiable and so it’d be up to the developer using it to ensure that they too were meeting the requirements. This might be acceptable, but there’s also a chance that Twitter would object.

The former, requiring OAuth authentication for all API requests, is unfortunately a show stopper. OAuth requires registering an application with Twitter (easy) and using secret access tokens as authorization to the API (the problem). The reason this is a problem is that JavaScript runs client-side and can be fully inspected by any user, so the secret access tokens are not very “secret” and could easily be reused by someone else for nefarious purposes.

The OAuth issues could be worked around by implementing the badge server-side in PHP or another language, but then it would not be the same paste-in solution it currently is. I could create a web service that acted as the middle-man, allowing one to create badges that would be populated using a small amount of JavaScript and allowed me to control the majority of the CSS styling with hooks for specific theming, but then you might as well just use the official Twitter Embedded Timelines badges.

So, the future for my Twitter Statuses JavaScript Badge looks bleak. It’s highly likely that this is its last six months, which is too bad as I still had features planned. I’m not going to call it quits yet as I’ve got a number of months to consider my options, but discontinuing it is definitely on the table.

One such function was Perform(), which allows dynamically sending a message to a frame. I say was because, with Makoto Nukui (NEWT/0’s developer) pointing (and re-pointing) me in the right direction, I was able to implement all the message sending global functions, namely: Apply(), Perform(), PerformIfDefined(), ProtoPerform(), and ProtoPerformIfDefined(). All of which have been merged back to master, so they’re at your disposal if you build newt from the latest source.

No need to go into details on the implementation, the functionality was already there and just needed to be wrapped around, but I did want to discuss usage of Perform(). I won’t cover its variants as they’re called the same way, they just allow silent failures (in the case of *IfDefined()) or different inheritance searching (in the case of Proto*()).

As I mentioned above, Perform() allows you to more dynamically send a message to a frame. For example, let’s take the following frame which has a Test() method:

someFrame := {
	Test: func () begin
		Print("Hello world.\n");
	end
};

Normally, if we wanted to send the someFrame frame a message of Test, we’d do so as follows:

someFrame:Test();

And it would execute the Test method, outputting:

Hello world.

Well, what if you didn’t know until runtime how many arguments you should need to pass along with message you’re sending? That’s where Perform comes in. It takes three arguments: the frame you want to send the message to, a symbol denoting which method should be called, and an array of parameters to send to said method (or nil if not passing any arguments). So, building on our previous example, like so:

Perform(someFrame, 'Test, nil);

Or, if one were passing parameters along with the message:

Perform(someOtherFrame, 'SomeOtherMethod, ["parameter 1", 2]);

Note the use of the quoted constant, 'Test & 'SomeOtherMethod, naming the method to be called. What if you also didn’t know the name of the method until runtime? How can you convert a string to a symbol to pass to Perform()? Fortunately, there’s Intern(), which returns a symbol when passed a string. With that, we can fully dynamically send a message to a frame, as follows:

methodName := "Test";
Perform(someFrame, Intern(methodName), nil);

This is all documented in The NewtonScript Programming Language (PDF; mirrors: UNNA, Newted), but it’s spread out a bit, so figured I’d summarize it all in one place. I’d love to see others start playing with NewtonScript more as well.

That said, I do see use for the bash implementation.

Why bash?

Most of my bash scripts are are exercises to keep my bash-fu honed, so this one certainly started that way and did so as a part of tools-osx. While not a modern, object-oriented language, I find bash to be there for me on nearly every platform I use (excluding the obvious like pre-Mac OS X, Newton OS, etc.) without needing to build or install anything else. There are feature differences between versions, but they are minor.

It’s very much in the spirit of UNIX and forces you to use the other command-line tools at your disposal, in conjunction with each other. So, I find it a great way to master more command-line tools and also to become a better command-line user. The more I learn in bash the more I’m able to do efficiently on the command-line, esp. complex tasks. As a server admin, this is immensely helpful. And, the server admin in me is probably why I find it greatly comforting to not have to install or maintain another language and its tools.

It’s a relatively minimalist language and lacks a lot of niceties, but I consider it a bit of a survivalist language at this point. It’s no Perl, Python, or Ruby and it may be frustrating to work with arrays or return anything but integers, but if you can master it you’ll be able to be tossed into any random server and come out alive.

So, Why realpath in bash?

The real benefit for a realpath implementation in bash is the portability without the need to compile for new platforms. Simply copy to the appropriate directory and you’re done. This is ideal for situations where you cannot guarantee a compiler will be available (the use-case for tools-osx) or cannot have a compiler installed (one I commonly encounter in my admin work due to various security requirements, but also one people with shared hosts often run into).

I was also recently contacted by someone who is using my realpath implementation in part of the process for launching a Java app on Linux and Mac OS X, so in this case it’s ideal to keep everything extremely portable with only one codebase and no build process required. Exactly the kind of thing I had in mind.

In Conclusion

So, the bash implementation of realpath has a couple of use-cases, mostly if you’re shooting for no compile process for installation. If you’ve already got a compile process, you’ll probably be better off with the C implementation for performance and to reduce your codebase. If you’re Linux-only, or platforms where you already have readlink available, just use readlink. Naturally, this is all with bash scripting in mind, most higher languages have a built-in realpath function.

Fortunately, it’s quite easy to emulate using pwd, but there is a bit of extra work that must be done. I found a good, portable example, but it still wasn’t quite up to my standards. I’ve simplified & improved it and the result is as follows (last updated 2012-11-29):

function realpath()
{
	local success=true
	local path="$1"

	# make sure the string isn't empty as that implies something in further logic
	if [ -z "$path" ]; then
		success=false
	else
		# start with the file name (sans the trailing slash)
		path="${path%/}"

		# if we stripped off the trailing slash and were left with nothing, that means we're in the root directory
		if [ -z "$path" ]; then
			path="/"
		fi

		# get the basename of the file (ignoring '.' & '..', because they're really part of the path)
		local file_basename="${path##*/}"
		if [[ ( "$file_basename" = "." ) || ( "$file_basename" = ".." ) ]]; then
			file_basename=""
		fi

		# extracts the directory component of the full path, if it's empty then assume '.' (the current working directory)
		local directory="${path%$file_basename}"
		if [ -z "$directory" ]; then
			directory='.'
		fi

		# attempt to change to the directory
		if ! cd "$directory" &>/dev/null ; then
			success=false
		fi

		if $success; then
			# does the filename exist?
			if [[ ( -n "$file_basename" ) && ( ! -e "$file_basename" ) ]]; then
				success=false
			fi

			# get the absolute path of the current directory & change back to previous directory
			local abs_path="$(pwd -P)"
			cd "-" &>/dev/null

			# Append base filename to absolute path
			if [ "${abs_path}" = "/" ]; then
				abs_path="${abs_path}${file_basename}"
			else
				abs_path="${abs_path}/${file_basename}"
			fi

			# output the absolute path
			echo "$abs_path"
		fi
	fi

	$success
}

Here’s a simple example of its usage:

relative_path="../Shared/"
absolute_path="$(realpath "$relative_path")"
if [ $? -eq 0 ]; then
	echo "absolute_path = $absolute_path"
else
	echo "'$relative_path' does not exist!"
fi

I have also tossed together a realpath tool which wraps around this implementation if you would like to install it for use in multiple scripts/tools. Feel free to download it from the development page or get the source code on GitHub. It’s released under a BSD license.

After digging through the NEWT/0 source code again, it appeared that I could again use GetGlobalVar(), but this time with the '_ENV_ object literal, but it didn’t seem to have anything useful in it, certainly not any environment variables. So, back to the source code I went and discovered that NEWT/0 implements a custom global function GetEnv(), like the getenv() equivalent in C, accepts a string for the environment variable name and returns the value stored in said environment variable.

To get the PATH environment variable, for example:

#!/usr/bin/env newt

Print("PATH:" && GetEnv("PATH") && "\n");

Or a basic “hello world” CGI that also echoes the query string:

#!/usr/local/bin/newt

Print("Content-Type: text/plain\n\n");

Print("Hello world!\n\n");
Print("QUERY_STRING:" && GetEnv("QUERY_STRING") && "\n");

I must thank NEWT/0’s developer, Makoto Nukui, for including all this functionality!

I’ve also had NEWT/0, an open source, cross-platform NewtonScript interpreter, installed for a while. Since it can run NewtonScript scripts from the command line like any other interpreter, I decided I’d like to know if it was possible to get the command line arguments from NewtonScript so I could eventually write some local scripts to get myself familiar with the syntax & functions (therefore less of a learning curve when I finally get around to writing some actual Newton packages). After a point in the right direction from Matthias Melcher and a lot of digging through the NEWT/0 source code, I finally figured out how to do so.

Here’s a quick NewtonScript script that can be run through NEWT/0 to print out the command line arguments you pass to it:

#!/usr/bin/env newt

Print("'_ARGV_ exists? ");
if GlobalVarExists('_ARGV_) then Print("Yes.\n") else Print("No.\n");

foreach slot, value in GetGlobalVar('_ARGV_) do Print(slot && ":"
&& value && "\n");

I doubt there are many, if any, out there that are interested in doing this, but—who knows?—maybe somebody else will start scripting in NewtonScript too. (Expect to see some more NewtonScript-related news around here in the future.)

When I released v0.7 of my Twitter Statuses JavaScript Badge back in November of last year, it was right around the time that Twitter was rolling out their new ‘snowflake’ status ID generator which was going to have some implications for languages such as JavaScript. Unfortunately, I didn’t become aware of this until I started seeing random issues with status IDs a couple months later. More unfortunately, I’m only getting around to applying the minor tweak to fix this, and a minor issue with applying the ‘last’ class when there’s only one LI element, now.

Without further ado, I present v0.7.1! Please accept my apologies for sitting on this issue for so long and let me know if you have any questions, comments, or feature requests. Also, the source code is on GitHub.

FYI – I started developing a major update back in March, including a few frequently requested features. Hopefully I’ll get that polished up sometime this year.

• trash can now list trash contents across all volumes (with a disk usage total) as well as empty the trash (including a secure empty option; both emptying operations require confirmation).

Note: Obviously, the new version of trash is now destructive. I have tested and use this myself, but I cannot guarantee it won’t securely erase your entire hard drive if it encounters some odd edge case and I cannot be held responsible for that. So, use at your own risk and keep backups!

Go download them all (clipcat, eject, swuser, and trash) or get the source code on github!

The sde_newsletter plug-in helps build HTML, text, or multipart email messages from Textpattern pages (although, technically, you can use any web-facing source HTML & text). It’s straightforward and very powerful when paired with newsletter/mailing list software.

Update: I discovered a minor bug parsing page title from HTML if the TITLE element contains line breaks. This has been resolved in v0.5.1.

• swuser gives you control of Mac OS X’s Fast User Switching from the command line, including options for switching to login window, user by name, or user by ID. Unfortunately, it’s not compatible with screen.

Go download them all (clipcat, eject, swuser, and trash) or get the source code on github!