I'm trying to create a Makefile that uses information from the path to create a relevant rpm name. Suppose I have two different possible paths:
PATH1 = /usr/local/home/jsmith/code/main
PATH2 = /usr/local/home/jsmith/code/dev/ver2
If "main" is detected in the path, I want to detect and append "main" to the rpm name. If "dev" is detected in the path, I want to detect and append "ver2" to the rpm name.
I'm new to shell scripting and really don't have a good idea on where to start. I could easily do this in something like python, but its for a Makefile so I need to do it in shell.
"main" in the path would be constant, but if "main" doesn't exist, the dev path name would need to be extracted. Here's a few mow examples:
/usr/local/home/jsmith/code/main
/usr/local/home/jsmith/code/dev/ver_usa
/usr/local/home/jsmith/code/dev/ver_mexico
/usr/local/home/jsmith/code/dev/ver3
If "dev" existed, it would be needed to extract "ver_usa", "ver_mexico", "ver3", etc. The dir name needing to be extracted would exactly follow "dev".
something like this, assuming "main" and "ver2" are not constant
some_rpm_name="some rpm"
PATH=/usr/local/home/jsmith/code/main
#PATH2=/usr/local/home/jsmith/code/dev/ver2
s=${PATH##*/}
case "$s" in
*main ) RPM_NAME="${some_rpm_name}_main";;
*ver2) RPM_NAME="${some_rpm_name}_ver2";;
esac
echo $RPM_NAME
Use grep and check for return value?
Also, you can run python in Makefile.
It looks like the last element of the path is always the one you want.
rpmname=$rpmname+${pathname##*/}
or
rpmname=$rpmname+$(basename pathname)
Related
I want to schedule my Perl code to be run every day at a specific time. so I put the below code in bash file:
Automate.sh
#!/bin/sh
perl /tmp/Taps/perl.pl
The schedule has been specified in below path:
10 17 * * * sh /tmp/Taps/Automate.sh > /tmp/Taps/result.log
When the time arrived to 17:10 the .sh file hasn't been running. however, when I run ./Automate.sh (manually) it is running and I see the result. I don't know what is the problem.
Perl Code
#!/usr/bin/perl -w
use strict;
use warnings;
use Data::Dumper;
use XML::Dumper;
use TAP3::Tap3edit;
$Data::Dumper::Indent=1;
$Data::Dumper::Useqq=1;
my $dump = new XML::Dumper;
use File::Basename;
my $perl='';
my $xml='';
my $tap3 = TAP3::Tap3edit->new();
foreach my $file(glob '/tmp/Taps/X*')
{
$files= basename($file);
$tap3->decode($files) || die $tap3->error;
}
my $filename=$files.".xml\n";
$perl = $tap3->structure;
$dump->pl2xml($perl, $filename);
print "Done \n";
error:
No such file or directory for file X94 at /tmp/Taps/perl.pl line 22.
X94.xml
foreach my $file(glob 'Taps/X*') -- when you're running from cron, your current directory is /. You'll want to provide the full path to that Taps directory. Also specify the output directory for Out.xml
Cron uses a minimal environment and a short $PATH, which may not necessarily include the expected path to perl. Try specifying this path fully. Or source your shell settings before running the script.
There are a lot of things that can go wrong here. The most obvious and certain one is that if you use a glob to find the file in directory "Taps", then remove the directory from the file name by using basename, then Perl cannot find the file. Not quite sure what you are trying to achieve there. The file names from the glob will be for example Taps/Xfoo, a relative path to the working directory. If you try to access Xfoo from the working directory, that file will not be found (or the wrong file will be found).
This should also (probably) lead to a fatal error, which should be reported in your error log. (Assuming that the decode function returns a false value upon error, which is not certain.) If no errors are reported in your error log, that is a sign the program does not run at all. Or it could be that decode does not return false on missing file, and the file is considered to be empty.
I assume that when you test the program, you cd to /tmp and run it, or your "Taps" directory is in your home directory. So you are making assumptions about where your program looks for the files. You should be certain where it looks for files, probably by using only absolute paths.
Another simple error might be that crontab does not have permission to execute the file, or no read access to "Taps".
Edit:
Other complications in your code:
You include Data::Dumper, but never actually use that module.
$xml variable is not used.
$files variable not declared (this code would never run with use strict)
Your $files variable is outside your foreach loop, which means it will only run once. Since you use glob I assumed you were reading more than one file, in which case this solution will probably not do what you want. It is also possible that you are using a glob because the file name can change, e.g. X93, X94, etc. In that case you will read the last file name returned by the glob. But this looks like a weak link in your logic.
You add a newline \n to a file name, which is strange.
I have a program in which I use a lot "../" which is to go one level up
in the file system and run some process on the directory with specific name. I have a command line tool in Go.
I have 3 questions
there is nicer way to do it instead of “../“
is there a const with which I can use instead of “/“
if 2 is not available should I create “constants“ under that internal package to share the “/“ between packages since I need it in
many place (from diff packages...)
example
dir.zip("../"+tmpDirName, "../"+m.Id+".zip", "../"+tmpDirName)
Set a variable, and use that everywhere:
path := "../"
or
path := ".." + string(os.PathSeparator)
then later:
dir.zip(path+tmpDirName, path+m.Id+".zip", path+tmpDirName)
This makes it very easy to change the path in the future, via a command line option, configuration, or just editing the value.
Yes. os.PathSeparator is the OS-specific path separator for the current architecture.
n/a
declare a global const somewhere, but I would just use ".." everywhere
os.PathSeparator
use filepath.Join("..", someDir, someFilename)
CLISP's interface to PARI is configured with the configure.in containing AC_LIB_LINKFLAGS([pari]) from lib-link.m4.
The build process also requires the Makefile to know where the datadir of PARI is located. To this end, Makefile.in has
prefix = #LIBPARI_PREFIX#
DATADIR = #datadir#
and expects to find $(DATADIR)/pari/pari.desc (normally
/usr/share/pari/pari.desc or /usr/local/share/pari/pari.desc).
This seems to work on Mac OS X where PARI is installed by homebrew in /usr/local (and LIBPARI_PREFIX=/usr/local), but not on Ubuntu, where PARI is in /usr, and LIBPARI_PREFIX is empty.
How do I insert the location of the PARI's datadir into the Makefile?
PS. I also asked this on the autoconf mailing list.
PPS. In response to #BrunoHaible's suggestion, here is the meager attempt at debugging on Linux (where LIBPARI_PREFIX is empty).
$ bash -x configure 2>&1 | grep found_dir
+ found_dir=
+ eval ac_val=$found_dir
+ eval ac_val=$found_dir
You are trying to use $(prefix) in an unintended way. In an Autotools-based build system, the $(prefix) represents a prefix to the target installation location of the software you're building. By setting it in your Makefile.in, you are overriding the prefix that configure will try to assign. However, since you appear not to have any installation targets anyway, at least at that level, that's probably more an issue of poor form than a cause for malfunction.
How do I insert the location of the PARI's datadir into the Makefile?
I'd recommend computing or discovering the needed directory in your configure script, and exporting it to the generated Makefile via its own output variable. Let's take the second part first, since it's simple. In configure.in, having in some manner located the wanted data directory and assigned it to a variable
DATADIR=...
, you would make an output variable of that via the AC_SUBST macro:
AC_SUBST([DATADIR])
Since you are using only Autoconf, not Automake, you would then manually receive that into your Makefile by changing the assignment in your Makefile.in:
DATDIR = #DATADIR#
Now, as for locating the data directory in the first place, you have to know what you're trying to implement before you can implement it. From your question and followup comments, it seems to me that you want this:
Use a data directory explicitly specified by the user if there is one. Otherwise,
look for a data directory relative to the location of the shared library. If it's not found there then
(optional) look under the prefix specified to configure, or specifically in the specified datadir (both of which may come from the top-level configure). Finally, if it still has not been found then
look in some standard locations.
To create a configure option by which the user can specify a custom data directory, you would probably use the AC_ARG_WITH macro, maybe like this:
AC_ARG_WITH([pari-datadir], [AS_HELP_STRING([--with-pari-datadir],
[explicitly specifies the PARI data directory])],
[], [with_pari_datadir=''])
Thanks to #BrunoHaible, we see that although the Gnulib manual does not document it, the macro's internal documentation specifies that if AC_LIB_LINKFLAGS locates libpari then it will set LIBPARI_PREFIX to the library directory prefix. You find that that does work when the --with-libpari option is used to give it an alternative location to search, so I suggest working with that. You certainly can try to debug AC_LIB_LINKFLAGS to make it set LIBPARI_PREFIX in all cases in which the lib is found, but if you don't want to go to that effort then you can work around it (see below).
Although the default or specified installation prefix is accessible in configure as $prefix, I would suggest instead going to the specified $datadir. That is slightly tricky, however, because by default it refers to the prefix indirectly. Thus, you might do this:
eval "datadir_expanded=${datadir}"
Finally, you might hardcode a set of prefixes such as /usr and /usr/local.
Following on from all the foregoing, then, your configure.in might do something like this:
DATADIR=
for d in \
${with_pari_datadir} \
${LIBPARI_PREFIX:+${LIBPARI_PREFIX}/share/pari} \
${datadir_expanded}/pari \
/usr/local/share/pari \
/usr/share/pari
do
AS_IF([test -r "$[]d/pari.desc"], [DATADIR="$[]d"; break])
done
AS_IF([test x = "x$DATADIR"], [AC_MSG_ERROR(["Could not identify PARI data directory"])])
AC_SUBST([DATADIR])
Instead of guessing the location of datadir, why don't you ask PARI/GP where its datadir is located? Namely,
$ echo "default(datadir)" | gp -qf
"/usr/share/pari"
does the trick.
So when coding a bash/sh script I got a path in a variable with the following content:
$SOMEPATH=/usr/lib64/pkgconfig/../..
How can I convert $SOMEVAR to a full absolute path that converts the ".." folders to this value?:
$SOMEFULLPATH=/usr
Thanks
You could use readlink:
readlink -f "$SOMEPATH"
-f, --canonicalize
canonicalize by following every symlink in every component of
the given name recursively; all but the last component must
exist
-m, --canonicalize-missing
canonicalize by following every symlink in every component of
the given name recursively, without requirements on components
existence
Similar to the answer from #devnull I would recommend readlink, however the -m option does not require any part of the file path to already exist, which is more flexible.
readlink -m $SOMEFULLPATH
Where should the trailing semicolon in the Windows PATH environment variable be placed when adding a new folder?
Is it
[oldPATH];C:\My Folder
[oldPATH]C:\My Folder;
[oldPATH];C:\My Folder;
?
I saw different practices.
This is not really a syntax thing, actually. The correct answer here is: Place the semicolon so the result is a valid PATH.
This usually means one of the following:
set PATH=%PATH%;C:\Foo\Bar
set PATH=C:\Foo\Bar;%PATH%
because usually PATH doesn't end in a semicolon, so you have to add one appropriately to not mangle an existing path in it.
Just look at how PATH looks like and consider what you need to do if you add another path. This means you have to add a separator (the semicolon) and the path itself.
The first one. At least thats what Windows does on mine, so if Windows does it that way then that will probably be best :)
The first one:
[oldPATH]; C:\My Folder.
If you want to be sure, you can use the formula:
"%PATH%;C:\My Folder".
If it is only to execute something in, for example, a BAT script, use:
SET PATH "%PATH%;C:\My Folder".
(this one will be working just as a temporal variable)
To add a permanent User Enviroment Variable through command line:
SETX PATH "%PATH%;C:\My Folder".
Your oldPATH may end with semicolon, so when using fourth style [newPath];[OldPath] you don't add double semicolons.
path=%cd%;%path%
Note that windows doesn't care whether you write commands upper- or lowercase.