[ale] ubuntu install has no $PATH?

[Michael B. Trausch]

On Sun, 2011-07-24 at 22:50 -0400, Jim Kinney wrote:
> A friend who is a very green Linux user installed Ubuntu (latest
> whatever version) and went to install adobe flash. It required some
> command line-fu (which he didn't have) so he called me.
> 
> -> I'm not an ubuntu person <-

Doesn't (much) matter, it's a GNU/Linux system not terribly unlike the
others... as long as the Canonical-specific, Shuttlecock-stroking,
not-invented-here specific stuff is ignored, that is...

> So I was trying to find out what file type he was trying to install so
> I asked hi to open a terminal (he was in the normal X session) and run
> ls and tell me the name of the file he downloaded.
> 
> It errored with "no command or file by than name". So I had him do a
> "pwd". Same error. Ditto on "echo $PATH"
> 
> W   T   F    !!!!!
> 
> the command he _needed_ to run was sudo apt-get flash.....   but he
> couldn't recall if it was saved in the Downloads directory or the home
> directory. So he tried to cd and it failed.

Well, stock install, two commands:

### Install aptitude, which is a much more helpful package manager.
$ sudo apt-get install aptitude

### Install Flash.
$ sudo aptitude install flashplugin-installer

> Unfortunately, we were talking over the cell phones while I was in a
> busy and loud store so literally spelling out each letter of a working
> PATH "alpha bravo charlie" style was not going to happen.
> 
> Now I have been pretty harsh on messed up distro stupids in the past
> but I can't fathom how an install could complete and leave no working
> path variables set.
> 
> Any ideas how during an install (that appeared to conclude correctly)
> Ubuntu could have left off PATH? More importantly, ideas on how to NOT
> recreate this?

I would like to see the user's system.  Failing that, I would like to
see a tarball of the /var/log directory, *especially* if this is a clean
installation.  Also of the files generated by the following commands:

$ dpkg -l | gzip > packages.list.gz
$ cat /etc/environment > environment.gz
$ sudo tar cvf ./settings.tar.gz \
    /etc/environment /etc/login.defs /etc/skel /etc/adduser.conf \
    /etc/apt /etc/dpkg

If the output of all of those looks correct, then I think we can
eliminate the installer as a cause altogether.

I am going to guess that this is a complex failure, one that could
easily have been generated by a fault in hardware (perhaps a single
corrupt page in memory or something).  Of course, it's possible that a
software failure is to blame as well.  But the next thing I would do is
run memtest86+ on the thing for 12 hours.

	--- Mike

-- 
Michael B. Trausch                                       mike at trausch.us