Better to create a symbolic link than an alias I think. An alias might make substitutions on your command line when you didn't want one; creating a symlink will allow you to run the program as you want:
sudo ln -s full_path_to_opt/LightTable/deploy/LightTable /usr/local/bin
This will create a shortcut in /usr/local/bin (which should be in your PATH already!) to where LightTable actually is. Note also that you can rename the symlink as well if you don't like the capital letters in "LightTable":
sudo ln -s full_path_to_opt/LightTable/deploy/LightTable /usr/local/bin/lighttable
Just for reference, if the program is awkwardly designed, i.e. complains about not finding configuration files or libraries or whatever, then another solution that might be more useful is creating a wrapper script. To do this just create a file (wherever you like for the time being) called "LightTable" (or whatever else you like) with this in it:
#!/bin/sh
# Simple script to run LightTable
if ! cd full_path_to_opt/LightTable/deploy/LightTable ; then
echo "$0: error: LightTable directory not found." >&2
exit 1
fi
exec ./LightTable
Change the permissions of this file:
chmod 755 <wrapper_script>
and try executing it just to see if it works, and if so then move it to /usr/local/bin:
sudo mv -i <wrapper_script> /usr/local/bin
PATH
environment variable is often not the best way to achieve this, and may sometimes even break the system or create security vulnerabilities. (One must consider any other executables that will be turned into commands from this, as well as where inPATH
it's added.) Adding a shell alias, as covered by answers here, is better for anyone who doesn't want to consider such complexities; it is also more narrowly tailored to the specific app in question. Thus this is not a duplicate of that question, though they do overlap a little bit.