Bug 37290 - New port: tool for setting the title of xterms
Summary: New port: tool for setting the title of xterms
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-20 16:50 UTC by Andrew Stevenson
Modified: 2003-01-16 14:35 UTC (History)
0 users

See Also:


Attachments
file.shar (1.86 KB, text/plain)
2002-04-20 16:50 UTC, Andrew Stevenson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Stevenson 2002-04-20 16:50:01 UTC
Smool tool to set the window and icon titles of terminal emulator windows like
those of xterm, eterm and Terminal.app (MacOS X).
Comment 1 Doug Barton freebsd_committer freebsd_triage 2002-04-21 01:19:46 UTC
	I don't object to this port, however I would like to point out
that this functionality exists already in every modern shell I can think
of. For example:

http://dougbarton.net/Bash/Bash-prompts.txt
Comment 2 Andrew Stevenson 2002-04-21 03:58:41 UTC
On Sat, 20 Apr 2002, Doug Barton wrote:

> 	I don't object to this port, however I would like to point out
> that this functionality exists already in every modern shell I can think
> of. For example:

...and when it doesn't they can just call printf(1). New users however may
not know how to do it - it doesn't realy worry me one way or the other
though.

Andrew
Comment 3 Cy Schubert freebsd_committer freebsd_triage 2002-04-21 03:58:48 UTC
State Changed
From-To: open->feedback

Why do we need this port?  The following shell script can set XTerm 
titles without the overhead of a port: 

function title { 
echo -n '^[]0;' 
echo -n $1 
echo -n '^G' 
}
Comment 4 Cy Schubert 2002-04-21 04:18:44 UTC
In message <200204210310.g3L3A2E31747@freefall.freebsd.org>, Andrew 
writes:
> The following reply was made to PR ports/37290; it has been noted by GNATS.
> 
> From: Andrew <andrew@ugh.net.au>
> To: Doug Barton <DougB@FreeBSD.org>
> Cc: FreeBSD-gnats-submit@FreeBSD.org
> Subject: Re: ports/37290: New port: tool for setting the title of xterms
> Date: Sun, 21 Apr 2002 12:58:41 +1000 (EST)
> 
>  On Sat, 20 Apr 2002, Doug Barton wrote:
>  
>  > 	I don't object to this port, however I would like to point out
>  > that this functionality exists already in every modern shell I can think
>  > of. For example:
>  
>  ...and when it doesn't they can just call printf(1). New users however may
>  not know how to do it - it doesn't realy worry me one way or the other
>  though.

I do object because it doesn't add any  functionality that we cannot 
already do using other more simple means, yet it adds bloat to our 
ports tree.  Unless you object, I will close the PR.


Cheers,                          Phone:  250-387-8437
Cy Schubert                        Fax:  250-387-5766
Team Leader, Sun/Alpha Team      Email:  Cy.Schubert@osg.gov.bc.ca
Open Systems Group, CITS
Ministry of Management Services
Province of BC            
                    FreeBSD UNIX:  cy@FreeBSD.org
Comment 5 Cy Schubert freebsd_committer freebsd_triage 2002-04-21 05:06:36 UTC
State Changed
From-To: feedback->open

Everyone knows my opinion about this.  If the majority wants it, I won't 
stand in anyones way of committing this.
Comment 6 Doug Barton freebsd_committer freebsd_triage 2002-04-21 05:39:51 UTC
On Sun, 21 Apr 2002, Andrew wrote:

> Shall we rewrite all programs in the Bourne shell?

	No, just the parts of the base that rely on perl. :)

> There are a number that could be. I don't really mind if it gets
> commited or not but I thought it should be the end users choice as to
> what they install or if they wirte scripts to do what they need.

	The question isn't what we allow the users to use (of course),
it's about what we support in the ports tree. Given that (as far as I
know) csh-derived shells can also do this without help, and this
functionality is already provided by another program in ports, this port
is redundant, and probably shouldn't be included.

Doug
Comment 7 edwin 2002-04-21 07:31:34 UTC
On Sat, Apr 20, 2002 at 09:39:51PM -0700, Doug Barton wrote:
> > There are a number that could be. I don't really mind if it gets
> > commited or not but I thought it should be the end users choice as to
> > what they install or if they wirte scripts to do what they need.
> 
> 	The question isn't what we allow the users to use (of course),
> it's about what we support in the ports tree. Given that (as far as I
> know) csh-derived shells can also do this without help, and this
> functionality is already provided by another program in ports, this port
> is redundant, and probably shouldn't be included.

This argument shows that there is confusion what the ports collection
is for. As far as I see it (feel free to discuss this) The ports
collection-skeleton (the directory structure, the makefiles), that's
maintained by the FreeBSD team. But the actual ports itself, they're
maintained by their maintainers. Sometimes the persons who made
them, sometimes the persons who use them and who want to give
something back to the FreeBSD community.

There are ports which add something new to the operating system (a
webserver, a newsserver), there are ports which improve the current
utilities on the operating system (shells, utilities, editors) and
there are ports which replace things in the opearting system (MTAs,
X-servers, gcc).
Besides that, there are multiple versions of the same ports (with
and without IPv6, newer versions of a programming language or
toolkit) and there are multiple ports of the same functionality
(webservers, webbrowsers, instant messagers).

Refusing a port because there is something with the same functionality
is not done, towards the person who put effort in it to port it (I
remember my first port) and towards the future (if the port currently
available is removed from the distribution point and the author
isn't reachable anymore).

So yeah, if it was up to me then all the ports submitted would be
accepted, regardless of their functionality. The only reason not
to accept a port is because on technical grounds (isn't fetchable,
doesn't compile), not on functionality.

Just my 2 cents,
Edwin

-- 
Edwin Groothuis      |           Personal website: http://www.MavEtJu.org
edwin@mavetju.org    |        Interested in MUDs? Visit Fatal Dimensions:
bash$ :(){ :|:&};:   |                    http://www.FatalDimensions.org/
Comment 8 Edwin Groothuis freebsd_committer freebsd_triage 2003-01-16 14:35:38 UTC
State Changed
From-To: open->closed

Commited, thanks!