Even twiki.org uses cgi-bin and our use of the 'bin' name is simply inappropriate given its cgi-scripts content.

Furthermore, we need a place to put non-cgi stuff. Like 'UpgradeTWiki' for instance. (In TWiki20040901 it occurs in the root of the directory tree, i.e. /twiki/UpgradeTWiki).

-- MartinCleaver - 05 Sep 2004

It's also a problem for scripts like mailernotify and actionnotify that really shouldn't be in a CGI-bin directory.

-- CrawfordCurrie - 05 Sep 2004

Please don't. This would make the URL longer for sites which can't use the approaches outlined in ShorterURLs. Can the *notify scripts be subbed out of ManageCgiScript the same way RelockingRCSFiles is?

-- MattWilkie - 05 Sep 2004

Most people can use ShorterURLs, although for those that cannot we should have a method. This should not be too har now that we have a CommonFrontEndCgiScript.

Not using standards in the distro conflicts with the conventions used by the many for the few.

1. it is confusing for newbies
2. it conflicts with tools that cater to the conventions of /lib /bin /cgi-bin (e.g. the Eclipse IDE Editor)
3. It is in the way for a real /bin directory
4. The few who do have a weird setup can always rename /cgi-bin/ to /twiki, or /t, for example.

WRT the notify scripts - hopefully they will fall out of either the TWikiCLI (shell access to plugins) system I am building into BuildContrib or through the generalised CronHandler I proposed in MorePluginHooks. All the same, we will need a bin directory not accessible through the web.

-- MartinCleaver - 05 Sep 2004

Anyway, who can't use ShorterURLs?

-- MartinCleaver - 27 Oct 2004

As MartinCleaver pointed out, even TWiki.org is using cgi-bin and CrawfordCurrie has also good arguments for renaming it, I see no reason not to do so.

There seems to be only positive effects by changing the bin to cgi-bin besides the added 4 characters in the URL, which can be solved through ShorterURLs

-- AndreUlrich - 27 Oct 2004

Lots of people can't use ShorterURLs, because they don't have control over the system-wide httpd.conf file for Apache. The rationale seems rather weak for this, so I suggest we don't do it. If we need a non-CGI directory, we can come up with another name for it, e.g. utils.

-- RichardDonkin - 27 Oct 2004

I use ShorterURLs fine with .htaccess on three public .htaccess based sites.

Did you forget to vote or do you object in some way?

-- MartinCleaver - 27 Oct 2004

There seem to be some drawbacks to using .htaccess based URLs (blind debugging, restarting engine, etc), having read comments from RobNapier who seems to know mod_rewrite, and not all hosting providers enable this anyway, so we shouldn't assume that everyone can use ShorterURLs. If people are using ShorterURLs, the name of the bin directory doesn't matter anyway... I prefer a short standard URL i.e. using bin - TWiki.org is only using cgi-bin because of SourceForge hosting restrictions.

-- RichardDonkin - 27 Oct 2004

I care most that we don't misuse the "bin" dir. (conventions say this is for command line scripts, not cgi).

Quite what the cgi directory is called I don't really care because of the ShorterUrls system.

How about we rename our bin 'cgi'?

The problem is that people drop 'bin' scripts they find elsewhere into TWiki's 'bin' directory forgetting or not realising that doing so makes it executable to the world via CGI.

We need a different name for this dir so that people treat it like CGI and so that scripts found on the internet have somewhere to go.

-- MartinCleaver - 16 Dec 2004

I personally don't want bin renamed cgi-bin unless/until ShorterURLs works on hosts without mod_rewrite. I suppose I'd be okay with cgi.

Martin, earlier you asked who ShorteURLs doesn't work for: me, on both of my public twikis. On one mod_rewrite is not an option period, on the other I could probably ask for it, but twiki is too slow already and I don't want to do anything which will slow it down anymore. : )

As for executables which are "don't execute from browser", both 'utils' and 'tools' work for me.

In the end, I'll go with the majority.

-- MattWilkie - 17 Dec 2004

I really don't see the point of renaming bin - it is already a nice short name for those who have don't have ShorterURLs, and those who do don't care anyway. TWiki is not a command line oriented system, so it's fair enought that bin is a CGI directory, and we can call the command line tools directory something like cmd or util if we want - I agree that UpgradeTWiki should live in another directory, probably util or admin for admin tools. Also, ModPerl or SpeedyCGI systems don't really use CGI so cgi-bin is not a great name for their scripts either.

The work involved in changing all the docs and UpgradeTWiki far outweighs the very minor possible benefit of doing this compared to (say) working on TWikiSecurity or WYSIWYG editing. If people drop random scripts into the bin directory without realising it's a CGI directory, I don't think a name change is going to save them, as they will also be failing to set correct permissions and so on - AdminSkillsAssumptions is relevant here.

-- RichardDonkin - 17 Dec 2004

I disagree, better to leave as is:

• bin is short
• a new util can be introduced for non-cgi scripts
• it is possible to set the visual part of the URL in the Apache config or a rewrite rule (at work we use url /do/view/Web/Topic to indicate an action)

-- PeterThoeny - 23 Dec 2004

my opinion:

• use b instead of bin
• non-cgi should go outside the reach of the web server. a util/ (or just u/) would be nice.
• I have added a scripts/ dir myself for local CGI scripts not coming from the TWiki distrib

-- ColasNahaboo - 19 Jan 2005

I can't see that b means anything. Its not as bad as bin, but even tools is better. (Suddenly 4 years of twiki overrides decades of use convention of bin /bin, /usr/bin, /usr/local/bin and 10 years of CGI). Furthermore, if you want shorter than cgi-bin, cgi qualifies.

DevelopBranch's bin/twiki script is an example of a CommonFrontEndCgiScript: i.e. have one script that reads every request and calls the right TWiki::UI:: method. (see that topic).

-- MartinCleaver - 20 Jan 2005

I propose that we introduce util for non-CGI scripts, moving UpgradeTWiki and other non-CGI tools there, and don't change the bin directory name.

There really isn't enough justification for the hassle of changing the directory name everywhere including many docs. Some are for the name change, some are against it, and I can't see the disruption justifying what is claimed to be a nicer name.

-- RichardDonkin - 20 Jan 2005

I second Richard's suggestion.

-- MattWilkie - 20 Jan 2005

I came by this topic because a Dakar bug report referenced it. Please do not rename bin to cgi-bin.

• Check on Google for TWiki sites. How many of of them use short URLs? Very very few. You will break 1000s of links pointing to existing TWiki sites from other places. This is the most important killer argument against remaning bin
• If I look at my office TWiki I am fighting with lusers using absolute URLS instead of web.topic notation. Our TWiki is full of these links with http://domain/twiki/bin/view/topicname. And they will all be broken.
• cgi-bin becomes part of the user interface (URL is visible to users) and it is geeky enough already. People will write cgi_bin etc. The old cgi-bin naming convention is awful in the first place and if you look around the internet at professionel web sites you rarely see this as part of URLs anymore. Webmasters/sysadmins create a more friendly name of a subdirectory in the htdocs tree and activate CGI in it to make more friendly URLs.
• ShorterURLs topic lists as many problems as it lists solutions. And it seems many have trouble getting it to work. You read it and you quickly get convinced that it is too complicated to bother trying. That is probably why so few use it in practical and why most TWikis has 'bin' in the URL.

It is too late to change bin to cgi-bin and the arguments for the renaming are rather weak. If you rename bin to cgi-bin existing TWiki admins will have to spend effort renaming it back to bin. Instead solve the problem with scripts that should not be accessible from CGI by making a new directory called whatever you feel like.

But please keep the bin name unchanged. The URL of your public website has a high value and you do not change it just for fun. It may have taken years for an organisation or business or open source project to get their site known and linked from everywhere. And for Intranet sites you cause chaos when links pointing to your TWiki no longer works. There may be 100s of references from other Internet sites and documents that will no longer work if you rename your URL. This is serious businees for many. Don't make it impossible to upgrade a TWiki installation.

-- KennethLavrsen - 08 Jan 2006

Following Kennet argument, if an administrator wants his TWiki to work with cgi-bin instead of bin, is not that difficult to do. Pehaps a HowTo document would be enough.

-- RafaelAlvarez - 08 Jan 2006

Kenneth is 100% right. And if you really want to go through the pain of touching that, then simply omit /bin rather than "bragging" that you use CGI. Ad ShorterURLs: anybody got that really working? Don't remember the details, but an empty $dispViewPath screwed tings for me... /twiki/view, /twiki/edit, /twiki/pub looks like the best compromise, which you can have now - if you still bother.

-- PeterKlausner - 17 Jan 2006