management prints full path to script when command error occurs

[miracle2k]

PS > django-admin startapp --invalid
Usage: G:\Programme\Python\25\Scripts\django-admin.py startapp [options] [appname]

Fixed by using os.path.basename() in BaseCommand.run_from_argv.

[Malcolm Tredinnick]

That change would mean it gives the wrong results when you run it from some relative path on any Unix-derived system. The only small visual inconsistency here is that Windows gives slightly non-standard values for sys.argv[0] (the traditional return value is the path from where the command is run -- a relative path, not an absolute one). Plus, the value displayed for Windows isn't actually wrong. So I don't think this is worth doing -- replacing a correct display with something that will be incorrect in certain other situations would be a regression.

[miracle2k]

Hm, are you sure Malcolm? The *basename(sys.argv[0])* approach is also used in management.init when handling errors not specific to a certain command:

michael@giver:/$ /usr/bin/django-admin.py help startapp 2>&1| head -n 1
Usage: django-admin.py startapp [options] [appname]
michael@giver:/$ /usr/bin/django-admin.py startapp --invalid 2>&1| head -n 1
Usage: /usr/bin/django-admin.py startapp [options] [appname]
michael@giver:/$

That seems like an inconsistency both on Windows and *nix. basename() should return the actual filename (presumably what we would want) on all platforms.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Claude Paroz <claude@…>]

In c24e979ece2729716593291d3ebd81fdf7fc3b7d:

Fixed #7762 -- Hidden full script name in command error output