In order to do simple checks (e.g. date) without using files I tried the following (without sucess):
Store date in enviroment variable:
fs0:\> date >v date_var
Shell: Incorrect redirection syntax - '>v'
as an alternative I tried to pipe the result of date:
fs0:\> date | check_date.nsh
date: Too many arguments
Do I need certain lib or command level to run the above character sequences?
I´m using a uefi shell with:
EFI Shell version 2.40 [5.10]
Current running mode 1.1.2
...
fs0:\> ver
EFI Specification Revision : 2.40
Uefi_Shell_Spec_2_2 chapter 3.4.4 let me think that both should work fine.
If I remember correctly, UEFI shell does not support process piping, nor variable piping, so you cannot chain outputs, but it do support file redirections.
try to use data > date_file.
Related
Edit: Note this is an older question, from a time when AWS CLI was v1 - as noted in comments, there are other likely better solutions with v2
I'm using AWS CLI on Windows to query items from DynamoDb. Some of these items include non-ASCII characters.
When the query hits those items, it dies with an error
'charmap' codec can't encode character u'u010d' in position....
After hours of searching, I finally stumbled across a hackish workaround; under the AWSCLI\encodings directory, I copied utf_8.pyc over cp1252.pyc. This allows me to continue, but of course is ugly.
Before resorting to that, I also tried setting environment variables such as LANG, LC_ALL, LC_CTYPE to various permutations of en-US.UTF-8 or similar, all with no effect that I could see.
Does anyone know how (or is it even possible) to tell AWS CLI to use a particular encoding?
Since you're using the command line interface, a change to the terminal's encoding scheme should fix the issue.
Type:
chcp 65001
in the console (for UTF-8; you may also try different encodings) and retry your operations.
Maybe it could help as well - the issue with translation from AWS and storing results to the file (or powershell variable):
With error:
aws translate translate-text --text "Investigation" --source-language-code "auto" --target-language-code "PL" >> a.txt
'charmap' codec can't encode character '\u015a' in position 1: character maps to
Adding env. variable fixes the problem
set PYTHONIOENCODING=UTF-8
aws translate translate-text --text "Investigation" --source-language-code "auto" --target-language-code "PL" >> a.txt
The same in powershell:
PS C:\Users\???\Documents> $aws = aws translate translate-text --text "Request" --source-language-code "auto"--target-language-code "PL"
'charmap' codec can't encode character '\u015b' in position 4: character maps to <undefined>
PS C:\Users\???\Documents> exit
C:\Users\???\Documents>set PYTHONIOENCODING=UTF-8
C:\Users\???\Documents>powershell
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\Users\???\Documents> $aws = aws translate translate-text --text "Request" --source-language-code "auto"
--target-language-code "PL"
PS C:\Users\???\Documents> $aws
{
"TranslatedText": "Prośba",
"SourceLanguageCode": "en",
"TargetLanguageCode": "pl"
}
I've reinstalled AWS CLI using upgraded MSI installers which now use Python 3 instead of Python 2 and the unknown encoding error is now gone.
I am using git bash on windows 10 and set PYTHONIOENCODING=UTF-8 was not actually did env change. Used export PYTHONIOENCODING=UTF-8 then overcame the charmap error
for Windows 10 and cli is installed by python
Error:
'charmap' codec can't encode characters in position XX-XX: character maps to
Solution: run following command in command-line
set PYTHONIOENCODING=UTF-8
I have a Korn Shell script, and one part of it is that it takes a given date in YYYYMMDD format and outputs it in YYYY/MM/DD format. At first I tried
typeset displaystart=`date --date="${gbegdate}" '+%Y/%m/%d'`
which works fine on Linux, but Solaris's date doesn't have a --date option. I then tried
typeset displaystart=`echo ${gbegdate:0:4}`/`echo ${gbegdate:4:2}`/`echo ${gbegdate:6:2}`
which also works on Linux, but on Solaris it just outputs //.
How can I format this date string in a way that works on Linux and Solaris?
The ${variable:start:length} extension to POSIX shell syntax was introduced in the version of ksh released in 1993, precisely named ksh93, and was also introduced in bash 1.13 the very same year.
The Advanced bash scripting guide from the Linux Documentation Project states:
Variable expansion / Substring replacement
These constructs have been adopted from ksh.
${var:pos}
Variable var expanded, starting from offset pos.
${var:pos:len}
Expansion to a max of len characters of variable var,
from offset pos. See Example A-13 for an example of the creative use
of this operator.
The issue is that on Solaris 10 and older, /bin/ksh is providing a previous ksh standard, ksh88, which didn't implemented this feature.
On the other hand, on Linux, ksh is often ksh93 which supports substring extraction. That explains why your script works under Linux ksh (if you really tested it on ksh.)
An old derivative of ksh93 is available on Solaris 10 though. It is named dtksh ans is located in /usr/dt/bin/dtksh. Your command should work unchanged with it however I wouldn't recommend to fully switch to dtksh, this shell being phased out from Solaris but you might still use it from a regular ksh script to workaround your issue:
typeset displaystart=$(/usr/dt/bin/dtksh -c "gbedate=$gbedate; echo \${gbegdate:0:4}/\${gbegdate:4:2}/\${gbegdate:6:2}")
Note that Solaris 11 and newer provide both GNU date and ksh93 so you wouldn't have that issue in the first place.
Korn shell doesn't have ${variable:start:length} syntax; this is a bash extension to POSIX shell syntax.
You can use echo "$variable" | cut -cstart-end instead.
typeset displaystart=`echo $gbegdate | cut -c1-4`/`echo $gbegdate | cut -c5-6`/`echo $gbegdate | cut -c7-8`
Or maybe you could change your script to use bash instead of ksh.
I need to strictly bind every core file generated by system to certain bin version of crashed application. I can specify core-name pattern in sysctl.conf:kernel.core_pattern, but there is no way to put bin version here.
How can I put the version of crashed program into core file (revision number) or any other way to determine version of crashed bin?
I'm using qmake VERSION variable in .pro file, which contains revision number from SVN. Its available by QCoreApplication::applicationVersion(), in my every bin by flag --version.
Assuming your app can get far enough to print out its version number without a core dump, you can write a small program (python would probably be easiest) that is invoked by a core dump. The program would read stdin, dump it to a file, then rename the file based on the version number.
From man 5 core:
Piping core dumps to a program
Since kernel 2.6.19, Linux supports an alternate syntax for the
/proc/sys/kernel/core_pattern file. If the first character of this
file is a pipe symbol (|), then the remainder of the line is inter‐
preted as a program to be executed. Instead of being written to a disk
file, the core dump is given as standard input to the program. Note
the following points:
* The program must be specified using an absolute pathname (or a path‐
name relative to the root directory, /), and must immediately follow
the '|' character.
* The process created to run the program runs as user and group root.
* Command-line arguments can be supplied to the program (since Linux
2.6.24), delimited by white space (up to a total line length of 128
bytes).
* The command-line arguments can include any of the % specifiers
listed above. For example, to pass the PID of the process that is
being dumped, specify %p in an argument.
If you call your script /usr/local/bin/dumper, then
echo "| /usr/local/bin/dumper %E" > /proc/sys/kernel/core_pattern
The dumper should copy stdin to a file, then try to run the program named on its command line to extract a version number and use that to rename the file.
Something like this might work (I haven't tried it, so use at extreme risk:)
#!/usr/bin/python
import sys,os,subprocess
from subprocess import check_output
CORE_FNAME="/tmp/core"
with open(CORE_FNAME,"f") as f:
while buf=sys.stdin.read(10000):
f.write(buf)
pname=sys.argv[1].replace('!','/')
out=subprocess.check_output([pname, "--version"])
version=out.split('\n')[0].split()[-1]
os.rename(CORE_FNAME, CORE_FNAME+version)
The really big risk of doing this is recursive core dumps that may crash your system. Be sure to use ulimit to only allow core dumps from processes that can print out their own versions without core dumping.
It would be a good idea to change the script to re-run the program to get the version info only if it is the program you are expecting.
I am using oozie to run my map-reduce job. I want to create the output file according to the date. But it takes date as a string and ends up printing instead of taking date as the value :
/user/skataria/geooutput/$(date +"%m%d%Y%H%M%S")
Here is the oozie properties file:
nameNode=hdfs://localhost:8020
jobTracker=localhost:8021
date=(date +"%m%d%Y%H%M%S")
oozie.wf.application.path=${nameNode}/services/advert/sid
inputDir=${nameNode}/user/${user.name}/geoinput/testgeo
outputDir=${nameNode}/user/${user.name}/geooutput/${date}
Somehow i cant have oozie as tag because my reputation is under 1500
It looks like you're trying to use a linux shell command (date +"%m%d%Y%H%M%S") in a java properties file - this isn't going to resolve.
One work around, assuming this is part of a manually submitted Workflow job (as opposed to a Coordinator job) is to provide the date property from the command line using the -D key=value option, and linux shell back quotes to resolve the output of a command inline
oozie job -run -config job.properties -D date=`date +"%m%d%Y%H%M%S"`
You'll need to make sure your version of Oozie support the -D key=value option
Yes I agree the shell option works. But that does not solve my usecase. I want to run my map-reduce job daily and schedule this thru Hue. The output directory needs to be parameterized as an job property to Oozie.
By the way I find that Oozie has Expression language Functions,
Unfortunately the function timestamp() returns the UTC current date and time in W3C format down to the second (YYYY-MM-DDThh:mm:ss.sZ). i.e.: 1997-07-16T19:20:30.45Z and completely unusable for creating a sub-directory name in HDFS
So for now,
I have a workaround. I am using the Workflow EL Function wf:id()
In workflow.xml
<property>
<name>mapreduce.output.fileoutputformat.outputdir</name>
<value>/user/sasubramanian/impressions/output/outpdir/${yyyy_mm_dd}/${wf:id()}</value>
</property>
This creates a output directory with subdirectory as,
/user/foouser/subdir1/output/outpdir/0000006-130321100837625-oozie-oozi-W
NOTE: You must specify this in the workflow.xml. This will not work if you specified it in the job.properties
Is there any MS-DOS command to get the version of am executable (or dll) file?
Of course there is a simple command ;-)
wmic /node:"servername" datafile where name='c:\\Program Files (x86)\\Symantec\\Symantec Endpoint Protection\\smc.exe' get version
you can ommit /node to perform check on the local computer. And if you ommit "get version" you get all the values and column names. Of course there are standard wmic parameters available like /output:filename, /append:filename or /format:csv and you can use #list.txt instead of a server name to perform check on list of machines.
Either user powershell
see
Get file version in PowerShell
or Windows Explorer
or write your own utility, I don't think that MSDOS supports this natively.
You could load the executable as a binary file and read the PE headers manually...
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
You can try Resource Hacker with the following syntax:
reshack.exe -extract "path\to\my\file.dll," ver.rc, VERSIONINFO, , && findstr FILEVERSION ver.rc
Beware of commas. Make sure you can create ver.rc.