# The form data below was edited by perforce
# Perforce Workshop Jobs
#
# Job: The job name. 'new' generates a sequenced job number.
#
# Status: Job status; required field. There is no enforced or
# promoted workflow for transition of jobs from one
# status to another, just a set of job status values
# for users to apply as they see fit. Possible values:
#
# open - Issue is available to be worked on.
#
# inprogress - Active development is in progress.
#
# blocked - Issue cannot be implemented for some reason.
#
# fixed - Fixed, optional status to use before closed.
#
# closed - Issue has been dealt with definitively.
#
# punted - Decision made not to address the issue,
# possibly not ever.
#
# suspended - Decision made not to address the issue
# in the immediate future, but noting that it may
# have some merit and may be revisited later.
#
# duplicate - Duplicate of another issue that.
#
# obsolete - The need behind the request has become
# overcome by events.
#
# Project: The project this job is for. Required.
#
# Severity: [A/B/C] (A is highest) Required.
#
# ReportedBy The user who created the job. Can be changed.
#
# ReportedDate: The date the job was created. Automatic.
#
# ModifiedBy: The user who last modified this job. Automatic.
#
# ModifiedDate: The date this job was last modified. Automatic.
#
# OwnedBy: The owner, responsible for doing the job. Optional.
#
# Description: Description of the job. Required.
#
# DevNotes: Developer's comments. Optional. Can be used to
# explain a status, e.g. for blocked, punted,
# obsolete or duplicate jobs. May also provide
# additional information such as the earliest release
# in which a bug is known to exist.
#
# Component: Projects may use this optional field to indicate
# which component of the project a givenjob is associated
# with.
#
# For the SDP, the list of components is defined in:
# //guest/perforce_software/sdp/tools/components.txt
#
# Type: Type of job [Bug/Feature]. Required.
#
# Release: Release in which job is intended to be fixed.
Job: job000222
Status: open
Project: p4perl
Severity: C
ReportedBy: reg_smith
ReportedDate: 2015/04/30 04:56:35
ModifiedBy: perforce
ModifiedDate: 2019/02/19 10:51:13
OwnedBy: reg_smith
Description:
Allow capture internally of the error from a failed $p4->connect() rather than going to scripts STDERR on terminal
(cross referenced to https://swarm.perforce.com/jobs/job078669)
If a call to $p4->connect fails:
$p4->Connect() or die( "Failed to connect to Perforce Server" );
..Connect() spits out an error message with a helpful hint to check P4PORT e.g.
Connect to server failed; check $P4PORT.
TCP connect to p4test11:1666 failed.
How can this message be intercept and have it in say $p4->Errors (or anywhere else in the script such a variable) and not to the terminal stderr output)?
Redefining the STDERR handle to point to a variable for example in the script doesn't capture it, it still goes to the terminal.
For example something like this doesn't populate $stderr
do {
local *STDERR;
# redirect STDERR to variable
open(STDERR, ">", \$stderr) or die "Can't open STDERR: $!";
eval {
$p4->Connect() or die "Error connecting $!" ;
}
if($@){
print "\$@ = $@";
print "strerr var = $stderr \n";
}
}
Wrapping the $p4->Connect in an eval block doesn't capture the useful message about checking the port to $! - that's still printed to STDERR on the terminal.
eval {
$p4->Connect() or die "Error connecting $!" ;
};
if($@){
# Do something before bailing out
print $@ ;
};
A real kludge would be to redirect the script stderr to a temp file and read that in (YUK!).
DevNotes:
Type: Feature