Sponsored Content
Operating Systems Solaris Command for checking modification history on file Post 302455298 by jlliagre on Tuesday 21st of September 2010 08:25:19 AM
Old 09-21-2010
The syntax I suggested works only with SunOS 5.11 based distributions. Sorry for not mentioning that.
This User Gave Thanks to jlliagre For This Post:
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

command for modification date of a file

Good morning, I would like to find all files of a certain type and display their name as well as their modification date. In order to do this, I would do the following: find ./ -name *.csv | ???????? My question: what to put after the pipe instead of the question marks? Is there a basic... (5 Replies)
Discussion started by: scampsd
5 Replies

2. Solaris

Modification history for Crontab

Hi all - I've searched the forums and seen a few questions related, but nothing which explicitly answers what I'm looking for. I need to know if there's ANY way to get the modification history of any users crontab. Yes, I know that crontabs are in /var/spool/cron. I know that the... (2 Replies)
Discussion started by: amcq
2 Replies

3. UNIX for Dummies Questions & Answers

How to track the modification history on file in unix

How do we track the modification history on a file in UNIX. IS there any command or any script that we could run. Many Thanks (5 Replies)
Discussion started by: RSPDaemon
5 Replies

4. Shell Programming and Scripting

File modification history

Can anyone please suggest an alternate command for "stat" . I am trying this on Solaris 5.9 , but the command doesn't exist. Basically i need to see one particalar file modification history. Any help is appreciated. (4 Replies)
Discussion started by: mk1216
4 Replies

5. UNIX for Advanced & Expert Users

History to Another file [local user history , but root access]

Hi all, My need is : 1. To know who , when , which command used. 2. Local user should not delete this information. I mean , with an example , i can say i have a user user1 i need to give all the following permissions to user1, : a. A specific directory other than his home... (3 Replies)
Discussion started by: linuxadmin
3 Replies

6. UNIX for Dummies Questions & Answers

History to Another file [local user history , but root access]

Hi all, My need is : 1. To know who , when , which command used. 2. Local user should not delete this information. I mean , with an example , i can say i have a user user1 i need to give all the following permissions to user1, : a. A specific directory other than his home... (1 Reply)
Discussion started by: sriky86
1 Replies

7. Shell Programming and Scripting

UNIX CO command for file version history

Hello :) I'm a newb when it comes to shell scripting and was wondering about a command(s) for a script that could be used to checkout a certain number of version/revision histories of a file. I know for the latest revison you "co filename" or for a certain revision number "co -r*.* filename"... (2 Replies)
Discussion started by: MN-DBA
2 Replies

8. AIX

Checking the command history file in AIX

Hello, The system has been rebooted and I need to see the commands executed in the system prior to restart by the oracle user.The history command is not showing me the commands executed prior to reboot. Please advise. Best regards, Vishal (1 Reply)
Discussion started by: Vishal_dba
1 Replies

9. AIX

Getting files through find command and listing file modification time upto seconds

I have to list the files of particular directory using file filter like find -name abc* something and if multiple file exist I also want time of each file up to seconds. Currently we are getting time up to minutes in AIX is there any way I can get file last modification time up to seconds. (4 Replies)
Discussion started by: Nitesh sahu
4 Replies

10. Shell Programming and Scripting

[ksh] how to reload history file without entering a command

I'm basically looking for the ksh equivalent of bash's PROMPT_COMMAND="history -r", where simply redrawing the command prompt in a terminal will cause ksh to reload the history file. At the risk of sounding incredibly lazy (in which case I would be guilty as charged), I've noticed that if I have... (13 Replies)
Discussion started by: DevuanFan
13 Replies
Module::Build::Bundling(3pm)				 Perl Programmers Reference Guide			      Module::Build::Bundling(3pm)

NAME
Module::Build::Bundling - How to bundle Module::Build with a distribution SYNOPSIS
# Build.PL use inc::latest 'Module::Build'; Module::Build->new( module_name => 'Foo::Bar', license => 'perl', )->create_build_script; DESCRIPTION
WARNING -- THIS IS AN EXPERIMENTAL FEATURE In order to install a distribution using Module::Build, users must have Module::Build available on their systems. There are two ways to do this. The first way is to include Module::Build in the "configure_requires" metadata field. This field is supported by recent versions CPAN and CPANPLUS and is a standard feature in the Perl core as of Perl 5.10.1. Module::Build now adds itself to "configure_requires" by default. The second way supports older Perls that have not upgraded CPAN or CPANPLUS and involves bundling an entire copy of Module::Build into the distribution's "inc/" directory. This is the same approach used by Module::Install, a modern wrapper around ExtUtils::MakeMaker for Makefile.PL based distributions. The "trick" to making this work for Module::Build is making sure the highest version Module::Build is used, whether this is in "inc/" or already installed on the user's system. This ensures that all necessary features are available as well as any new bug fixes. This is done using the new inc::latest module. A "normal" Build.PL looks like this (with only the minimum required fields): use Module::Build; Module::Build->new( module_name => 'Foo::Bar', license => 'perl', )->create_build_script; A "bundling" Build.PL replaces the initial "use" line with a nearly transparent replacement: use inc::latest 'Module::Build'; Module::Build->new( module_name => 'Foo::Bar', license => 'perl', )->create_build_script; For authors, when "Build dist" is run, Module::Build will be automatically bundled into "inc" according to the rules for inc::latest. For users, inc::latest will load the latest Module::Build, whether installed or bundled in "inc/". BUNDLING OTHER CONFIGURATION DEPENDENCIES
The same approach works for other configuration dependencies -- modules that must be available for Build.PL to run. All other dependencies can be specified as usual in the Build.PL and CPAN or CPANPLUS will install them after Build.PL finishes. For example, to bundle the Devel::AssertOS::Unix module (which ensures a "Unix-like" operating system), one could do this: use inc::latest 'Devel::AssertOS::Unix'; use inc::latest 'Module::Build'; Module::Build->new( module_name => 'Foo::Bar', license => 'perl', )->create_build_script; The "inc::latest" module creates bundled directories based on the packlist file of an installed distribution. Even though "inc::latest" takes module name arguments, it is better to think of it as bundling and making available entire distributions. When a module is loaded through "inc::latest", it looks in all bundled distributions in "inc/" for a newer module than can be found in the existing @INC array. Thus, the module-name provided should usually be the "top-level" module name of a distribution, though this is not strictly required. For example, Module::Build has a number of heuristics to map module names to packlists, allowing users to do things like this: use inc::latest 'Devel::AssertOS::Unix'; even though Devel::AssertOS::Unix is contained within the Devel-CheckOS distribution. At the current time, packlists are required. Thus, bundling dual-core modules, including Module::Build, may require a 'forced install' over versions in the latest version of perl in order to create the necessary packlist for bundling. This limitation will hopefully be addressed in a future version of Module::Build. WARNING -- How to Manage Dependency Chains Before bundling a distribution you must ensure that all prerequisites are also bundled and load in the correct order. For Module::Build itself, this should not be necessary, but it is necessary for any other distribution. (A future release of Module::Build will hopefully address this deficiency.) For example, if you need "Wibble", but "Wibble" depends on "Wobble", your Build.PL might look like this: use inc::latest 'Wobble'; use inc::latest 'Wibble'; use inc::latest 'Module::Build'; Module::Build->new( module_name => 'Foo::Bar', license => 'perl', )->create_build_script; Authors are strongly suggested to limit the bundling of additional dependencies if at all possible and to carefully test their distribution tarballs on older versions of Perl before uploading to CPAN. AUTHOR
David Golden <dagolden@cpan.org> Development questions, bug reports, and patches should be sent to the Module-Build mailing list at <module-build@perl.org>. Bug reports are also welcome at <http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Build>. SEE ALSO
perl(1), inc::latest, Module::Build(3), Module::Build::API(3), Module::Build::Cookbook(3), perl v5.18.2 2013-11-04 Module::Build::Bundling(3pm)
All times are GMT -4. The time now is 06:27 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy