Sponsored Content
Top Forums Shell Programming and Scripting Python: Refer a properties file from different location Post 303041133 by Neo on Friday 15th of November 2019 05:01:13 AM
Old 11-15-2019
Did you try hard coding the full path into your code for testing?
 

10 More Discussions You Might Find Interesting

1. HP-UX

Depot file properties

Hi How can we identify the informations like Author, meta data, dependency and other information from a depot file? (1 Reply)
Discussion started by: sethumadhavan
1 Replies

2. UNIX for Dummies Questions & Answers

File properties

Hi , I do have a line in my code as follows: if ] ; then ... else ... fi What does the -z does ? Similarly there is -s in some other part of the code. I guess there are many options like this.. Can anybody please tell what all options are available and what do they mean ? (2 Replies)
Discussion started by: risshanth
2 Replies

3. UNIX for Dummies Questions & Answers

Refer a remote file

I need to refer a remote(present on another unix server) directory from my unix machine as a local file. e.g. I have one directory D1 on 10.10.10.10 and i need to access files in this directory just like they are present on my unix machine 20.20.20.20. Is there any way out... i read a bit... (1 Reply)
Discussion started by: blackeyed
1 Replies

4. Shell Programming and Scripting

Put one string from one location to another location in a file

Hi Everyone, I have 1.txt here a b c' funny"yes"; d e The finally output is: here a b c d e' funny"yes"; (1 Reply)
Discussion started by: jimmy_y
1 Replies

5. Shell Programming and Scripting

reading in properties file

Hi Am new to this scripting stuff so bear with me. I got a script made now that reads in a properties file. The properties file is in the following format: 256= Bos, Sea, FRa 128= HEL I want to be able to read in each line of the file and split out the letter fields by the numbered field. This... (2 Replies)
Discussion started by: vsekvsek
2 Replies

6. Shell Programming and Scripting

File created in a different location instead of desired location on using crontab

Hi, I am logging to a linux server through a user "user1" in /home directory. There is a script in a directory in 'root' for which all permissions are available including the directory. This script when executed creates a file in the directory. When the script is added to crontab, on... (1 Reply)
Discussion started by: archana.n
1 Replies

7. Shell Programming and Scripting

How to copy a file from one location to another location?

I have file file1.txt in location 'loc1'. Now i want a copy of this file in location 'loc2' with a new file called test.txt. Please help me how to do this in shell script. (1 Reply)
Discussion started by: vel4ever
1 Replies

8. UNIX for Dummies Questions & Answers

Hot to retrieve *.sql file names which we refer in .sh file.

Hi Guys, How to retrieve/get *.sql file names which we refer in all *.sh files. Can any one help me on this. Thanks, Kolipaka (3 Replies)
Discussion started by: lakshmanrk811
3 Replies

9. UNIX for Dummies Questions & Answers

[Solved] How to refer to input file in code?

This may be a dumb question, but googling is not giving me an answer. I'm trying to figure out how to refer to an input file in my code. Lets say i run a script in bash: "sh shellscript.sh inputfile" (Inputfile will be variable...whatever file i run the script on) I wanted to make... (5 Replies)
Discussion started by: legato22
5 Replies

10. Shell Programming and Scripting

How to find a existing file location and directory location in Solaris box?

Hi This is my third past and very impressed with previous post replies Hoping the same for below query How to find a existing file location and directory location in solaris box (1 Reply)
Discussion started by: buzzme
1 Replies
Test::Perl::Critic::Policy(3)				User Contributed Perl Documentation			     Test::Perl::Critic::Policy(3)

NAME
Test::Perl::Critic::Policy - A framework for testing your custom Policies SYNOPSIS
use Test::Perl::Critic::Policy qw< all_policies_ok >; # Assuming .run files are inside 't' directory... all_policies_ok() # Or if your .run files are in a different directory... all_policies_ok( '-test-directory' => 'run' ); # And if you just want to run tests for some polices... all_policies_ok( -policies => ['Some::Policy', 'Another::Policy'] ); # If you want your test program to accept short Policy names as # command-line parameters... # # You can then test a single policy by running # "perl -Ilib t/policy-test.t My::Policy". my %args = @ARGV ? ( -policies => [ @ARGV ] ) : (); all_policies_ok(%args); DESCRIPTION
This module provides a framework for function-testing your custom Perl::Critic::Policy modules. Policy testing usually involves feeding it a string of Perl code and checking its behavior. In the old days, those strings of Perl code were mixed directly in the test script. That sucked. NOTE: This module is alpha code -- interfaces and implementation are subject to major changes. This module is an integral part of building and testing Perl::Critic itself, but you should not write any code against this module until it has stabilized. IMPORTABLE SUBROUTINES
all_policies_ok('-test-directory' => $path, -policies => @policy_names) Loads all the *.run files beneath the "-test-directory" and runs the tests. If "-test-directory" is not specified, it defaults to t/. "-policies" is an optional reference to an array of shortened Policy names. If "-policies" specified, only the tests for Policies that match one of the "m/$POLICY_NAME/imx" will be run. CREATING THE *.run FILES Testing a policy follows a very simple pattern: * Policy name * Subtest name * Optional parameters * Number of failures expected * Optional exception expected * Optional filename for code Each of the subtests for a policy is collected in a single .run file, with test properties as comments in front of each code block that describes how we expect Perl::Critic to react to the code. For example, say you have a policy called Variables::ProhibitVowels: (In file t/Variables/ProhibitVowels.run) ## name Basics ## failures 1 ## cut my $vrbl_nm = 'foo'; # Good, vowel-free name my $wango = 12; # Bad, pronouncable name ## name Sometimes Y ## failures 1 ## cut my $yllw = 0; # "y" not a vowel here my $rhythm = 12; # But here it is These are called "subtests", and two are shown above. The beauty of incorporating multiple subtests in a file is that the .run is itself a (mostly) valid Perl file, and not hidden in a HEREDOC, so your editor's color-coding still works, and it is much easier to work with the code and the POD. If you need to pass any configuration parameters for your subtest, do so like this: ## parms { allow_y => '0' } Note that all the values in this hash must be strings because that's what Perl::Critic will hand you from a .perlcriticrc. If it's a TODO subtest (probably because of some weird corner of PPI that we exercised that Adam is getting around to fixing, right?), then make a "##TODO" entry. ## TODO Should pass when PPI 1.xxx comes out If the code is expected to trigger an exception in the policy, indicate that like so: ## error 1 If you want to test the error message, mark it with "/.../" to indicate a "like()" test: ## error /Can't load Foo::Bar/ If the policy you are testing cares about the filename of the code, you can indicate that "fcritique" should be used like so (see "fcritique" for more details): ## filename lib/Foo/Bar.pm The value of "parms" will get "eval"ed and passed to "pcritique()", so be careful. In general, a subtest document runs from the "## cut" that starts it to either the next "## name" or the end of the file. In very rare circumstances you may need to end the test document earlier. A second "## cut" will do this. The only known need for this is in t/Miscellanea/RequireRcsKeywords.run, where it is used to prevent the RCS keywords in the file footer from producing false positives or negatives in the last test. Note that nowhere within the .run file itself do you specify the policy that you're testing. That's implicit within the filename. BUGS AND CAVEATS AND TODO ITEMS
Add policy_ok() method for running subtests in just a single TODO file. Can users mark this entire test as TODO or SKIP, using the normal mechanisms? Allow us to specify the nature of the failures, and which one. If there are 15 lines of code, and six of them fail, how do we know they're the right six? Consolidate code from Perl::Critic::TestUtils and possibly deprecate some functions there. Write unit tests for this module. Test that we have a t/*/*.run for each lib/*/*.pm AUTHOR
Andy Lester, Jeffrey Ryan Thalhammer <thaljef@cpan.org> COPYRIGHT
Copyright (c) 2009-2011 Andy Lester. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of this license can be found in the LICENSE file included with this module. perl v5.16.3 2014-06-09 Test::Perl::Critic::Policy(3)
All times are GMT -4. The time now is 08:01 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy