Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
aegis -New_File(1)	    General Commands Manual	    aegis -New_File(1)

NAME
	aegis new file - add new files to be created by	a change

SYNOPSIS
	aegis -New_File	file-name...  [	option...  ]
	aegis -New_File	-List [	option...  ]
	aegis -New_File	-Help

DESCRIPTION
	The aegis -New_File command is used to add new files to	a change.  The
	named files will be added to the list of files in the change.

	For each file named, a new file	is created in the development direc-
	tory, if it does not exist already.  If	the file already exists, it
	will not be altered.

	If you want a new source file to be executable (shell scripts, for ex-
	ample) then you	simply use the normal chmod(1) command.	 If any	of the
	file's executable bits are set at aede(1) time the file	is remembered
	as executable and all execute bits (minus the project's	umask) will be
	set by subsequent aecp(1) commands.

	If you name a directory	on the command line, the entire	directory tree
	will be	searched for new files.	 (Note:	absolutely everything will be
	added, including dot files and binary files, so	you will need to clean
	out any	junk first.)  Files below this named directory which are al-
	ready in the change, or	in the project,	will be	ignored.  The
	file_name_accept and file_name_reject patterns in the project
	aegis.conf file	will also be applied, see aepconf(5) for more informa-
	tion.

   Directory Example
	There are times	when a command such as
		$ aenf fubar/*
		aegis: project "example": change 42: "fubar/glorp" already in
		change
		aegis: project "example": change 42: found 1 fatal error, no
		new files added
		$
	will fail as shown.  There are several ways to deal with this, the
	easiest	being to simply	name the directory:
		$ aenf fubar
		aegis: project "example": change 42: file "fubar/smiley" added
		aegis: project "example": change 42: file "fubar/frownie"
		added
		$
	You could also use the find(1) command for arbitrarily complex file
	selection, but you must	first exclude files that the above command ex-
	cludes automatically:
		$ aelcf	> exclude
		$ aelpf	>> exclude
		$ find fubar -type f | \
		    grep -v -f exclude | \
		    xargs aegis	--new-file -v
		aegis: project "example": change 42: file "fubar/smiley" added
		aegis: project "example": change 42: file "fubar/frownie"
		added
		$
	If you aren't using the	exclude	list, the find(1) command will need
	fine tuning for	your development directory style.  If you are using
	the symlink-style, you will need to add	the find -nlink	1 option in
	addition to the	find -type f option.
		$ find fubar -type f -nlinks 1 | \
		    xargs aegis	--new-file -v
		aegis: project "example": change 42: file "fubar/smiley" added
		aegis: project "example": change 42: file "fubar/frownie"
		added
		$
	If you are using the full-copy development directory style, you	will
	have to	use the	exclude	list method, above.

   File	Templates
	When a new file	is created in the development directory	the project
	config file is searched	for a template for the new file.  If a tem-
	plate is found,	the new	file will be initialized to the	template, oth-
	erwise it will be created empty.  See aepconf(5) for more information.

	The simplest form is to	use template files, such as
		file_template =
		[
		    {
			pattern	= [ "*.c" ];
			body = "${read_file ${source template/c	abs}}";
		    },
		    {
			pattern	= [ "test/*/.sh" ];
			body = "${read_file ${source template/test abs}}";
		    },
		];
	As you can see,	the template files are part of the project source, so
	you can	add the	appropriate copyright notices, and wrappers, etc.  The
	$source	substitution locates them, if they are not part	of the current
	change (and they usually are not).

	The template files themselves contain substitutions.  The $filename
	substitution is	available, and contains	the name of the	file being
	created.  This can be manipulated in various ways when constructing
	the appropriate	file contents.	See aesub(5) for more information
	about substitutions.

	It is also possible to run a command to	create the new file.  You can
	do this	instead	of specifying a	body string, viz:
		file_template =
		[
		    {
			pattern	= [ "*"	];
			body_command = "perl ${source template.pl abs} $filename";
		    },
		];
	The command is run with	a current directory set	to the top of the de-
	velopment directory.  It is an error if	the command fails to create
	the file.  You can mix-and-match the two techniques, body string and
	body_command, if you want.

   File	Name Limitations
	There are a number of controls available to limit the form of project
	file names.  All of these controls may be found	in the project config-
	uration	file, see aepconf(5) for more information.  The	most signifi-
	cant are briefly described here:

	maximum_filename_length	= integer;
		This field is used to limit the	length of filenames.  All new
		files may not have path	components longer than this.  Defaults
		to 255 if not set.  For	maximum	portability you	should set
		this to	14.

	posix_filename_charset = boolean;
		This field may be used to limit	the characters allowed in
		filenames to only those	explicitly allowed by POSIX.  Defaults
		to false if not	set, meaning whatever your operating system
		will tolerate, except white space and high-bit-on characters.
		For maximum portability	you should set this to true.

	dos_filename_required =	boolean;
		This field may be used to limit	filenames so that they conform
		to the DOS 8+3 filename	limits and to the DOS filename charac-
		ter set.  Defaults to false if not set.

	windows_filename_required = boolean;
		This field may be used to limit	filenames so that they conform
		to the Windows98 and WindowsNT filename	limits and character
		set.  Defaults to false	if not set.

	shell_safe_filenames = boolean;
		This field may be used to limit	filenames so that they do not
		contain	shell special characters.  Defaults to true if not
		set.  If this field is set to false, you will need to use the
		${quote} substitution around filenames in commands, to ensure
		that filenames containing shell	special	characters do not have
		unintended side	effects.  Weird	characters in filenames	may
		also confuse your dependency maintenance tool.

	allow_white_space_in_filenames = boolean;
		This field may be used to allow	white space characters in file
		names.	This will allow	the following characters to appear in
		file names: backspace (BS, \b, 0x08), horizontal tab (HT, \t,
		0x09), new line	(NL, \n, 0x0A),	vertical tab (VT, \v, 0x0B),
		form feed (FF, \f, 0x0C), and carriage return (CR, \r, 0x0D).
		Defaults to false if not set.

		Note that this field does not override other file name fil-
		ters.  It will be necessary to explicitly set shell_safe_-
		filenames = false as well.  It will be necessary to set	dos_-
		filename_required = false (the default)	as well.  It will be
		necessary to set posix_filename_charset	= false	(the default)
		as well.

		The user must take great care to use the ${quote} substitution
		around all file	names in commands in the project configura-
		tion.  And even	then, substitutions which expect a space sepa-
		rated list of file names will have undefined results.

	allow_non_ascii_filenames = boolean;
		This field may be used to allow	file names with	non-ascii-
		printable characters in	them.  Usually this would mean a UTF8
		or international charset of some kind.	Defaults to false if
		not set.

		Note that this field does not override other file name fil-
		ters.  It will be necessary to explicitly set shell_safe_-
		filenames = false as well.  It will be necessary to set	dos_-
		filename_required = false (the default)	as well.  It will be
		necessary to set posix_filename_charset	= false	(the default)
		as well.

	filename_pattern_accept	= [ string ];
		This field is used to specify a	list of	patterns of acceptable
		filenames.  Defaults to	"*" if not set.

	filename_pattern_reject	= [ string ];
		This field is used to specify a	list of	patterns of unaccept-
		able filenames.

	Please Note: Aegis also	consults the underlying	file system, to	deter-
	mine its notion	of maximum file	size.  Where the file system's maximum
	file size is less than maximum_filename_length,	the filesystem wins.
	This can happen, for example, when you are using the Linux UMSDOS file
	system,	or when	you have an NFS	mounted	an ancient V7 filesystem.
	Setting	maximum_filename_length	to 255 in these	cases does not alter
	the fact that the underlying file systems limits are far smaller (12
	and 14,	respectively).

	If your	development directories	(or your whole project)	is on filesys-
	tems with filename limitations,	or a portion of	the heterogeneous
	builds take place in such an environment, it helps to tell Aegis what
	they are (using	the project config file's fields) so that you don't
	run into the situation where the project builds	on the more permissive
	environments, but fails	with mysterious	errors in the more limited en-
	vironments.

	If your	development directories	are routinely on a Linux UMSDOS
	filesystem, you	would probably be better off setting dos_filename_re-
	quired = true, and also	changing the development_directory_template
	field.	Heterogeneous development with various Windows environments
	may also require this.

   File	Name Interpretation
	The aegis program will attempt to determine the	project	file names
	from the file names given on the command line.	All file names are
	stored within aegis projects as	relative to the	root of	the baseline
	directory tree.	 The development directory and the integration direc-
	tory are shadows of this baseline directory, and so these relative
	names apply here, too.	Files named on the command line	are first con-
	verted to absolute paths if necessary.	They are then compared with
	the baseline path, the development directory path, and the integration
	directory path,	to determine a baseline-relative name.	It is an error
	if the file named is outside one of these directory trees.

	The -BAse_RElative option may be used to cause relative	filenames to
	be interpreted as relative to the baseline path; absolute filenames
	will still be compared with the	various	paths in order to determine a
	baseline-relative name.

	The relative_filename_preference in the	user configuration file	may be
	used to	modify this default behavior.  See aeuconf(5) for more infor-
	mation.

   Changing the	Type of	a File
	If you want to change the type of a file (say, from a test to a	source
	file, or vice versa) you could do it as	two changes, by	first using
	aerm(1)	in one change and then using aenf(1) or	aent(1)	in a second
	change,	or you can combine both	steps in the same change.  Remember to
	use the	aerm -nowhiteout option	or you will get	a most peculiar	new
	file template.

   File	Action Adjustment
	When this command runs,	it first checks	the change files against the
	projects files.	 If there are inconsistencies, the file	actions	will
	be adjusted as follows:

	create	If a file is being created, but	another	change set is inte-
		grated which also creates the file, the	file action in the
		change set still being developed will be adjusted to "modify".

	modify	If a file is being modified, but another change	set is inte-
		grated which removes the file, the file	action in the change
		set still being	developed will be adjusted to "create".

	remove	If a file is being removed, but	another	change set is inte-
		grated which removes the file, the file	will be	dropped	from
		the change set still being developed.

   Notification
	The new_file_command in	the project configuration file is run, if set.
	The project_file_command is also run, if set, and if there has been an
	integration recently.  See aepconf(5) for more information.

TEST CORRELATIONS
	The "aegis -Test -SUGgest" command may be used to have aegis suggest
	suitable regression tests for your change, based on the	source files
	in your	change.	 This automatically focuses testing effort to relevant
	tests, reducing	the number of regression tests necessary to be confi-
	dent that you have not introduced a bug.

	The test correlations are generated by the "aegis -Integrate_Pass"
	command, which associates each test in the change with each source
	file in	the change.  Thus, each	source file accumulates	a list of
	tests which have been associated with it in the	past.  This is not as
	exact as code coverage analysis, but is	a reasonable approximation in
	practice.

	The aecp(1) and	aenf(1)	commands are used to associate files with a
	change.	 While they do not actively perform the	association, these are
	the files used by aeipass(1) and aet(1)	to determine which source
	files are associated with which	tests.

   Test	Correlation Accuracy
	Assuming that the testing correlations are accurate and	that the tests
	are evenly distributed across the function space, there	will be	a less
	than 1/number chance that a relevant test has not been run by the
	"aegis -Test -SUGgest number" command.	A small	amount of noise	is
	added to the test weighting, so	that unexpected	things are sometimes
	tested,	and the	same tests are not run every time.

	Test correlation accuracy can be improved by ensuring that:

	o Each change should be	strongly focused, with no gratuitous file in-
	  clusions.  This avoids spurious correlations.

	o Each item of new functionality should	be added in an individual
	  change, rather than several together.	 This strongly correlates
	  tests	with functionality.

	o Each bug should be fixed in an individual change, rather than	sev-
	  eral together.  This strongly	correlates tests with functionality.

	o Test correlations will be lost if files are moved.  This is because
	  correlations are by name.

	The best way for tests to correlate accurately with source files is
	when a change contains a test and exactly those	files relating to the
	functionality under test.  Too many spurious files will	weaken the
	usefulness of the testing correlations.

OPTIONS
	The following options are understood

	-as-needed
		Usually	it is an error if a file is already in a change	set,
		and is redundantly added to the	change set again.  This	option
		says to	ignore such files.

	-Build
		This option may	be used	to specify that	the file is construc-
		ted during a build (often only an integrate build), so that
		history	of it may be kept.  This is useful for generating
		patch files, where a history of	generated files	is important.
		Files created in this way may not be copied into a change,
		though they may	be deleted.  Avoid using files of this type,
		if at all possible.

	-BAse_RElative
		This option may	be used	to cause relative filenames to be con-
		sidered	relative to the	base of	the source tree.  See aeu-
		conf(5)	for the	corresponding user preference.

	-CUrrent_RElative
		This option may	be used	to cause relative filenames to be con-
		sidered	relative to the	current	directory.  This is usually
		the default.  See aeuconf(5) for the corresponding user	pref-
		erence.

	-Change	number
		This option may	be used	to specify a particular	change within
		a project.  See	aegis(1) for a complete	description of this
		option.

	-CONFIGured
		This option may	be used	to specify that	the file is an Aegis
		project	configuration file.  The default project configuration
		file is	called aegis.conf, however any file name may be	used.
		You may	also use more than one file, splitting the content
		across several files, all of which must	be of this type.

	-Help
		This option may	be used	to obtain more information about how
		to use the aegis program.

	-INDependent
		The option may be used to request all the necessary actions,
		but not	to actually add	the new	file to	the change set.

	-Keep
		This option may	be used	to retain files	and/or directories
		usually	deleted	or replaced by the command.  Defaults to the
		user's delete_file_preference if not specified,	see aeuconf(5)
		for more information.

	-No_Keep
		This option may	be used	to ensure that the files and/or	direc-
		tories are deleted or replaced by the command.	Defaults to
		the user's delete_file_preference if not specified, see	aeu-
		conf(5)	for more information.

	-List
		This option may	be used	to obtain a list of suitable subjects
		for this command.  The list may	be more	general	than expected.

	-Not_Logging
		This option may	be used	to disable the automatic logging of
		output and errors to a file.  This is often useful when	sev-
		eral aegis commands are	combined in a shell script.

	-Project name
		This option may	be used	to select the project of interest.
		When no	-Project option	is specified, the AEGIS_PROJECT	envi-
		ronment	variable is consulted.	If that	does not exist,	the
		user's $HOME/.aegisrc file is examined for a default project
		field (see aeuconf(5) for more information).  If that does not
		exist, when the	user is	only working on	changes	within a sin-
		gle project, the project name defaults to that project.	 Oth-
		erwise,	it is an error.

	-TEMplate
		This option may	be used	to specify that	a new file template
		should be used,	even if	the file already exists.

	-No_TEMplate
		This option may	be used	to specify that	a new file template
		should not be used, even if the	file does not exist (any empty
		file will be created).

	-TERse
		This option may	be used	to cause listings to produce the bare
		minimum	of information.	 It is usually useful for shell
		scripts.

	-Universal_Unique_IDentifier string
		This option may	be used	to set the UUID	of a file.

	-Not_Universal_Unique_IDentifier
		This option may	be used	to require that	the file is created
		without	an UUID.  The aeipass-option:assign-file-uuid is set
		to false for the file to avoid automatic UUID assignment when
		aeipass(1) is invoked.

	-Verbose
		This option may	be used	to cause aegis to produce more output.
		By default aegis only produces output on errors.  When used
		with the -List option this option causes column	headings to be
		added.

	-Wait	This option may	be used	to require Aegis commands to wait for
		access locks, if they cannot be	obtained immediately.  De-
		faults to the user's lock_wait_preference if not specified,
		see aeuconf(5) for more	information.

	-No_Wait
		This option may	be used	to require Aegis commands to emit a
		fatal error if access locks cannot be obtained immediately.
		Defaults to the	user's lock_wait_preference if not specified,
		see aeuconf(5) for more	information.

	See also aegis(1) for options common to	all aegis commands.

	All options may	be abbreviated;	the abbreviation is documented as the
	upper case letters, all	lower case letters and underscores (_) are op-
	tional.	 You must use consecutive sequences of optional	letters.

	All options are	case insensitive, you may type them in upper case or
	lower case or a	combination of both, case is not important.

	For example: the arguments "-project", "-PROJ" and "-p"	are all	inter-
	preted to mean the -Project option.  The argument "-prj" will not be
	understood, because consecutive	optional characters were not supplied.

	Options	and other command line arguments may be	mixed arbitrarily on
	the command line, after	the function selectors.

	The GNU	long option names are understood.  Since all option names for
	aegis are long,	this means ignoring the	extra leading '-'.  The	"--op-
	tion=value" convention is also understood.

RECOMMENDED ALIAS
	The recommended	alias for this command is
	csh%	alias aenf 'aegis -nf \!* -v'
	sh$	aenf(){aegis -nf "$@" -v}

ERRORS
	It is an error if the change is	not in the being developed state.
	It is an error if the change is	not assigned to	the current user.
	It is an error if the file is already part of the change.
	It is an error if the file is already part of the baseline.
	It is an error if the files named on the command line are not normal
	files and not directories.  (If	you need symbolic links	or special
	files, create them at build time.)

EXIT STATUS
	The aegis command will exit with a status of 1 on any error.  The
	aegis command will only	exit with a status of 0	if there are no	er-
	rors.

ENVIRONMENT VARIABLES
	See aegis(1) for a list	of environment variables which may affect this
	command.  See aepconf(5) for the project configuration file's
	project_specific field for how to set environment variables for	all
	commands executed by Aegis.

SEE ALSO
	aecp(1)	copy files into	a change

	aedb(1)	begin development of a change

	aemv(1)	rename a file as part of a change

	aenfu(1)
		remove new files from a	change

	aent(1)	add new	tests to a change

	aerm(1)	add files to be	deleted	by a change

	aepconf(5)
		project	configuration file format

	aeuconf(5)
		user configuration file	format

COPYRIGHT
	aegis version 4.25.D510
	Copyright (C) 1991, 1992, 1993,	1994, 1995, 1996, 1997,	1998, 1999,
	2000, 2001, 2002, 2003,	2004, 2005, 2006, 2007,	2008, 2009, 2010,
	2011, 2012 Peter Miller

	The aegis program comes	with ABSOLUTELY	NO WARRANTY; for details use
	the 'aegis -VERSion License' command.  This is free software and you
	are welcome to redistribute it under certain conditions; for details
	use the	'aegis -VERSion	License' command.

AUTHOR
	Peter Miller   E-Mail:	 pmiller@opensource.org.au
	/\/\*		  WWW:	 http://miller.emu.id.au/pmiller/

Reference Manual		     Aegis		    aegis -New_File(1)

NAME | SYNOPSIS | DESCRIPTION | TEST CORRELATIONS | OPTIONS | RECOMMENDED ALIAS | ERRORS | EXIT STATUS | ENVIRONMENT VARIABLES | SEE ALSO | COPYRIGHT | AUTHOR

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=aenf&sektion=1&manpath=FreeBSD+12.0-RELEASE+and+Ports>

home | help