420323 - the command line for specifying the profile to use is problematic

Status: RESOLVED FIXED

(Camino Graveyard :: Product Site, defect)

Description

[Peter da Silva]

User-Agent:       Arena 1.0
Build Identifier: 

On http://caminobrowser.org/documentation/hiddenprefs/ it says:

open Terminal and enter the following command, all on one line, replacing ~/Documents/MyTestProfile with the path to your desired profile:

export CAMINO_PROFILE_DIR=~/Documents/MyTestProfile; open Camino.app

There are three problems with this.
* First, this will not work if the user has chosen csh or tcsh as their shell.
* Second, this makes a change that is inherited by all commands issued from the same shell window, rather than just for the "open" command on the same line.
* Third, if there are spaces in the profile name they need to be quoted.

I suggest changing this to:

env CAMINO_PROFILE_DIR="~/Documents/MyTestProfile" open Camino.app

* The "env" command will work correctly in all shells.
* The "env" command is a separate executable and does not change the calling shell's environment as the "export" built-in does.
* The use of quotes will ensure that the path is passed intact, even if there are metacharacters (like spaces) in the profile directory.


Reproducible: Always

Steps to Reproduce:
1. Open a terminal
2. Enter 'export CAMINO_PROFILE_DIR=~/Documents/MyTestProfile; open Camino.app'
3. Close camino
4. In the same terminal window, enter "open Camino.app".

Actual Results:  
Camino opens in the alternate profile.

Expected Results:  
Camino opens in the same profile.

I realize that most users will simply open a terminal window, issue the command, and close it, and the ones that don't are more likely to figure out what is going on.

An alternative might be to explain the difference between the Bourne and C shells and provide separate "export" and "setenv" commands, but I think my suggestion is simpler. :)

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #0)
> I realize that most users will simply open a terminal window, issue the
> command, and close it, and the ones that don't are more likely to figure out
> what is going on.

This documentation only exists for those people who understand what the commands do and how to convert between shells (as an aside, bash has been the default shell since 10.3, and our policy is to always employ the OS defaults in documentation).  Your "Expected Results" are incorrect for the intended users of this documentation ;)

We never point end users to this documentation of the env variable; instead, they are sent to http://pimpmycamino.com/parts/troubleshoot-camino which removes all of these complexities for them.

So, while your points are valid in the abstract case, I think that this bug is WONTFIX.

Comment 2

[Peter da Silva]

My suggested command line always works in every case where the original one does, and the original one is incorrect even for bash.

The correct command line for bash, not using the "env" command, is:

CAMINO_PROFILE_DIR="~/Documents/MyTestProfile" open Camino.app

with no "export" or semicolon. Adding "env" to the beginning of this line has been the standard way to portably specify single-command environment settings almost as long as as the Bourne shell has been publicly available, which is almost as long as I have been using UNIX (I was at Berkeley when 7th edition was released, and the "env" command came out of the port of csh to V7).

Comment 3

[Peter da Silva]

PS: I was a system administrator for a team of UNIX software developers for nearly 20 years, and you would be amazed at the things PhD programmers who have been using UNIX for a decade don't know. I think expecting people who think they know enough to read this page to understand that the "export" command is persistent is asking a bit much. :)

Comment 4

[Chris Lawson (gone)]

I definitely think the quotes around the path need to be added, as having spaces in path names is extremely common and it's an easy pitfall to avoid with a simple change on our part.

I'll let more Unix-savvy folks argue the various technical merits and drawbacks of the rest of Peter's suggestion, but I'm also inclined to say that unless his suggestion is downright *wrong*, a more universally applicable set of instructions is always a good thing.

Comment 5

[Stuart Morgan]

Let's change it to comment 2; it's simpler and better.

The small fraction of users who have manually changed their shell can adapt the command themselves.

Comment 6

[Peter da Silva]

Four additional characters to make a cut-and-paste command line work on any shell doesn't seem to be excessive complexity, and I still think you're assuming more sophistication from the target community than I've seen. I mean, I've had PhD programmers insist that they have to write their scripts in CSH because that's their default shell. At one point the head of the computer center at Berkeley broke every script on several of the Cory Hall 11/70s by putting "#!/bin/csh" at the head of them all. Even in a geekier environment and in geekier times, those four characters would have been useful. :)

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

FIXED per comment 5.