This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Reapply patch lost during recent "blind import" of libtool

On 11-May-2001, Loren James Rittle <> wrote:
> > Could the exit status of the script depend on some
> > command-line argument given to cvs commit?
> Unfortunately, under CVS, the filter that checks commits does not get
> any client-provided arguments.

If the client is connecting via ssh, as is normally (always?) the case
for the GCC cvs server, and it propagates X connections, which I think
is currently NOT the case for the GCC cvs server, then it's possible to
use that to open a window on the client's X server to ask the user
whether they want to commit anyway.  See the Perl subroutine below.
(I think this code doesn't actually work correctly, but hopefully
it is sufficient to demonstrate the concept.)

I'm not sure what security risks there would be with allowing ssh to
propagate X connections.

> > Another alternative I like is to get the commit script to test the
> > version numbers, at least in ltconfig and, and make sure
> > they're modified between the existing version and the one about to be
> > committed, and, if they don't differ, issue a hard error.  This would
> > guarantee that locally-modified files are clearly marked as such.
> I can see why you want that, but that is a tad harder to do I am
> afraid.  The commitinfo script has direct access to the names of files
> to be changed and indirect access to the contents of the files to be
> changed.  I don't know that one can legally run 'cvs update
> -rUNKNOWN-WHAT-GOES-HERE -p' to get a copy of the file to compare against.

Yes, doing that might deadlock.
However, if you use `cvs -n update', I think it should be OK.
Of course, that still leaves the problem of filling in


# returns non-zero if commit should go ahead
sub check_if_user_wants_to_force_commit {
	if (open TTY, "/dev/tty") {
		print "Commit anyway? [n] ";
		if (<TTY> =~ /^y/i) {
			return 1;
		} else {
			return 0;
	} else {
		my $file = shift(@_);
		my $result;
		my $have_X_display = $ENV{DISPLAY} ne "";

		if (! $already_remote) {
			# If this is the first time through, we have a few
			# extra things to do and say.

			$already_remote = 1;

			# We don't want the output to be (block) buffered
			$| = 1;

			print "\nCan't read from your terminal --- "
				. "you appear to be using remote CVS.\n";

			if ($have_X_display) {
				print "Trying X connection to "
					. "$ENV{DISPLAY}.\n\n";
			} else {
				print "You have no DISPLAY environment "
					. "variable set so I don't know\n"
					. "how to interact with you.  "
					. "Sorry.\n\n";

		return 0 unless $have_X_display;

		# Try interacting with the user via X.  This probably only
		# works when connecting via something such as ssh which
		# redirects X connections back to their origin.

		$result = system "xmessage", "-buttons", "yes:0,no:1",
				"Problem with `$file'.  Commit anyway?";
		$errcode = $result & 0xff;
		$exitval = $result >> 8;
		if ($errcode == 0 && ($exitval == 0 || $exitval == 1)) {
			return ! $exitval;
		} else {
			print "Error running `xmessage', sorry.\n";
			print "(Result code = ", $result, ")\n";
			return 0;

Fergus Henderson <>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <>  |     -- the last words of T. S. Garp.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]