I'm building my custom wrapper around wmic using node.js and I have problems parsing it's output. Not a problem, but I just don't know why this happens.
I thought line endings are either \r or \r\n and decided to look on it
Here's a demo piece of code:
exec('wmic process', {maxBuffer :1000*1024}, function (err, stdout, stderr){
let location =stdout.indexOf('\n')-6;
let region =stdout.substr(location, 10);
console.log(region);
let buf = new Buffer(stdout);
let buf2 = new Buffer(30);
buf.copy(buf2, 0, location, location+30);
console.log(buf2);
});
I looked at region and saw this:
For some reason there are two \rs instead of one!
Output of console.log(buf2) also shows this:
<Buffer 6f 75 6e 74 20 20 0d 0d 0a 53 79 73 ...
^^ ^^ ^^
I was ready to split lines by \r\r\n when I decided to pipe its output to text file and look through a hex editor:
wmic process > wmic.txt
What? Where are two \rs?
I have two questions:
Where does Node get second \r from? I tried to find some info, but Google is kind of heavy on queries such as \r\r\n, this is the closest I could get, I'm not sure if it's related
Why hex editor shows 16bit encoding and Node doesn't? I suppose I should've specified encoding in exec() options but I don't know which one. chcp shows 437th codepage, but I kind of want it to work in other codepages as well.
Related
How do I fix USER FATAL MESSAGE 740? This error is generated by Nastran when I try to run a BDF/DAT file of mine.
*** USER FATAL MESSAGE 740 (RDASGN)
UNIT NUMBER 5 HAS ALREADY BEEN ASSIGNED TO THE LOGICAL NAME INPUT
USER ACTION: CHANGE THE UNIT NUMBER ON THE ASSIGN STATEMENT AND IF THE UNIT IS USED FOR
PARAM,POST,<0 THEN SPECIFY PARAM,OUNIT2 WITH THE NEW UNIT NUMBER.
AVOID USING THE FOLLOWING UNIT NUMBERS THAT ARE ASSIGNED TO SPECIAL FILES IN MSC.NASTRAN:
1 THRU 12, 14 THRU 22, 40, 50, 51, 91, 92. SEE THE MSC.NASTRAN INSTALLATIONS/OPERATIONS
GUIDE SECTION ON MAKING FILE ASSIGNMENTS OR MSC.NASTRAN QUICK REFERENCE GUIDE ON
ASSIGN PHYSICAL FILE FOR REFERENCE.
Below is the head of my BDF file.
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
SOL 200
CEND
ECHO = NONE
DESOBJ(MIN) = 35
set 30=1008,1007,1015,1016
DESMOD=SUB1_PLATE
SUBCASE 1
$! Subcase name : DefaultLoadCase
$LBCSET SUBCASE1 DefaultLbcSet
ANALYSIS = STATICS
SPC = 1
LOAD = 6
DESSUB = 99
DISPLACEMENT(SORT1,PLOT,REAL)=ALL
STRESS(SORT1,PLOT,VONMISES,CORNER)=ALL
BEGIN BULK
param,xyunit,52
[...]
ENDDATA
Below is the solution
Correct
assign userfile='SUB1_PLAT.csv', status=UNKNOWN, form=formatted, unit=52
I shortened the name of CSV file to SUB1_PLAT.csv. This reduced the length of the line to 72 characters.
Incorrect
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
The file management section is limited to 72 characters, spaces included. The incorrect line stretches 73 characters. The nastran reader ignores the 73rd character and on. Instead of reading "unit=52" the reader reads "unit=5" which triggers the error.
|<--------------------- 72 Characters -------------------------------->||<- Characters are ignored truncated ->
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
References
MSC Nastran Reference Guide
The records of the first four sections are input in free-field format
and only columns 1 through 72 are used for data. Any information in
columns 73 through 80 may appear in the printed echo, but will not be
used by the program. If the last character in a record is a comma,
then the record is continued to the next record.
I'm developing the standard Node+Express web app. Everything else is working fine, but I can't make the .env file to populate process.env
At first, I thought it was a scope problem since my app.js, where dotenv is called from, is within the src subfolder and .env is in the root. But using node tools and confirming it with a package called find-config, I have the correct absolute path. I've never gotten an ENOENT for a file not found.
I tried everything, from dotenv's debug thingy explained in the docs, to my own debugging, making sure everything is in place. This is my latest attempt:
const fs = require('fs');
const realpath = require('find-config')('.env');
console.log(dotenv.parse(fs.readFileSync(realpath)));
I've paused execution and asserted that indeed realpath is exactly the absolute .env path
And here's .env
NODE_ENV=development
NODE_HOST=localhost
NODE_PORT=8080
SESSION_SECRET=eX&frsz9M*3XqFKUrK6
The console.log outputs {}, which is consistent with every avenue I've tried: never an error, never a parsed object either. Just nothingness.
Doing this:
const results = JSON.stringify(dotenv.config({"path":"/100%/correct/path/.env"}));
It throws back {"parsed":{}}
I've become so suspicious that I downloaded, installed and run the mega Hackathon Starter repo of 29k stars, which uses the same method.
Initially, it doesn't work because the author used a relative path. With the absolute path it works.
A bit more info in case it helps:
/* =========== Dotenv troubleshooting ===========
*/
const realPath = path.join(__dirname, '../.env');
const buffer = fs.readFileSync(realPath);
const envConfig = dotenv.parse(buffer, {debug:true});
l(realPath);
l(buffer);
l(envConfig);
/* end of Dotenv troubleshooting ------------------ */
This logs the following:
> node server.js
SESSION_SECRET=blabla value when parsing line 1: NODE_ENV=development
19:06:11 info: /100%/correct/path/.env
19:06:11 info: <Buffer 4e 4f 44 45 5f 45 4e 56 3d 64 65 76 65 6c 6f 70 6d 65 6e 74 0d 4e 4f 44 45 5f 48 4f 53 54 3d 6c 6f 63 61 6c 68 6f 73 74 0d 4e 4f 44 45 5f 50 4f 52 54 ... 41 more bytes>
19:06:11 info: {}
And as you can tell, that buffer is indeed the file:
/100%/correct/path $ xxd .env
00000000: 4e4f 4445 5f45 4e56 3d64 6576 656c 6f70 NODE_ENV=develop
00000010: 6d65 6e74 0d4e 4f44 455f 484f 5354 3d6c ment.NODE_HOST=l
After too much time scrutinizing my code, I finally discovered the issue.
Depending on operating systems and down to files themselves (and text editors and IDEs), at the end of the line you can have a Line Feed ("LF") character (0x0A, \n), Carriage Return ("CR") character (0x0D, \r) or End of Line ("EOL") character (0x0D0A, \r\n).
Unfortunately, dotenv only understands \n as the end of a line. So it was a parsing issue due to the simplicity of the checking. As far as I know, however, \n is kind of the standard.
For some reason, the .env file was using \r as a line separator. So it was a quick fix:
In my case, using a JetBrains product you can configure in the settings to always use the same end of line.
cpxSR2bnPUihaNxIFFA8Sc+8gUnWuJxJi8ywSW5ju0npWrFJHW2MSZAeMklcZ71IjrBySF2ci0gdecRI0vD/SM4ZF0m1ZSJJBY8bSZJl/0intaxIlQJBSPdY3EdBLM9Hp4wLSOK8Nki8L1pIoglxSAvNbkjHg0VIDlv7R6B2Y0elCqVGFWuVRgagAkdxHTdHELxRR9i2VkdyEUlHU84kRzTS2kalKFxG
This is a string from an XML file from my mass spectrometer. I am trying to write a program to load two such files, subtract one set of values from another, and write the results to a new file. According to the specification file for the .mzML format, the encoding of the numerical data is alleged to be base64. I can't convert this data string to anything legible using any of the many online base64 converter or using NotepaD++ and the MIME toolkit's base64 converter.
The string, in the context of the results file, looks like this:
<binaryDataArray encodedLength="224">
<cvParam cvRef="MS" accession="MS:1000515" name="intensity array" unitAccession="MS:1000131" unitName="number of counts" unitCvRef="MS"/>
<cvParam cvRef="MS" accession="MS:1000521" name="32-bit float" />
<cvParam cvRef="MS" accession="MS:1000576" name="no compression" />
<binary>cpxSR2bnPUihaNxIFFA8Sc+8gUnWuJxJi8ywSW5ju0npWrFJHW2MSZAeMklcZ71IjrBySF2ci0gdecRI0vD/SM4ZF0m1ZSJJBY8bSZJl/0intaxIlQJBSPdY3EdBLM9Hp4wLSOK8Nki8L1pIoglxSAvNbkjHg0VIDlv7R6B2Y0elCqVGFWuVRgagAkdxHTdHELxRR9i2VkdyEUlHU84kRzTS2kalKFxG</binary>
I can't proceed until I can work out what format this encoding is meant to be!
Thanks in advance for any replies.
You can use this trivial program to convert it to plaintext:
#include <stdio.h>
int main(void)
{
float f;
while (fread(&f, 1, 4, stdin) == 4)
printf("%f\n", f);
}
I compiled this to "floatdecode" and used this command:
echo "cpxSR2bnPUihaNxIFFA8Sc+8gUnWuJxJi8ywSW5ju0npWrFJHW2MSZAeMklcZ71IjrBySF2ci0gdecRI0vD/SM4ZF0m1ZSJJBY8bSZJl/0intaxIlQJBSPdY3EdBLM9Hp4wLSOK8Nki8L1pIoglxSAvNbkjHg0VIDlv7R6B2Y0elCqVGFWuVRgagAkdxHTdHELxRR9i2VkdyEUlHU84kRzTS2kalKFxG" | base64 -d | ./floatdecode
Output is:
53916.445312
194461.593750
451397.031250
771329.250000
1062809.875000
1283866.750000
1448337.375000
1535085.750000
1452893.125000
1150371.625000
729577.000000
387898.875000
248514.218750
285922.906250
402376.906250
524166.562500
618908.875000
665179.312500
637168.312500
523052.562500
353709.218750
197642.328125
112817.929688
106072.507812
142898.609375
187123.531250
223422.937500
246822.531250
244532.171875
202255.109375
128694.109375
58230.625000
21125.322266
19125.541016
33440.023438
46877.441406
53692.062500
54966.843750
51473.445312
42190.324219
28009.101562
14090.161133
Yet another Java Base64 decode with options to uncompress should you need it.
Vendor spec indicated "32-bit float" = IEEE-754 and specified little-endian.
Schmidt's converter shows the bit pattern for IEEE-754.
One more Notepad++ step to look at the hex codes:
Notepad++ TextFX plugin (after the Base64 decode you already did)
select the text
TextFX > TextFX Convert > Convert text to Hex-32
lets you look at the hex codes:
"000000000 72 9C 52 47 66 E7 3D 48- ... 6E 63 BB 49 |rœRGfç=H¡hÜHP
Little-endian: 47529C72 converts (via Schmidt) as shown above by David.
You can access such data from mzML files in Python through pymzML, a python interface to mzML files.
http://pymzml.github.com/
I'm trying to implement an ISO8589 message to a financial institution. They however, have a Web Service that I call and then I load the ISO8589 payload into an appropriate field of the WCF service.
I have created an ISO8589 message this way:
var isoMessage = new OpenIso8583.Net.Iso8583();
isoMessage.MessageType = Iso8583.MsgType._0100_AUTH_REQ;
isoMessage.TransactionAmount = (long) 123.00;
isoMessage[Iso8583.Bit._002_PAN] = "4111111111111111";
// More after this.
I can't seem to figure out how I can convert the isoMessage into an ASCII human readable format so I can pass it through to the web service.
Anyone have any idea how this can be done with this library? Or am I using this library the wrong way?
Thanks.
UPDATED:
I have figured out how to do this doing:
var asciiFormatter = new AsciiFormatter();
var asciiValue = asciiFormatter.GetString(isoMessage.ToMsg());
However, Now I am trying to take the isoMessage and pass the entire thing as hex string easily using OpenIso8583.Net, as follows:
var isoMessage = new OpenIso8583Net.Iso8583();
isoMessage.MessageType = Iso8583.MsgType._0800_NWRK_MNG_REQ;
isoMessage[Iso8583.Bit._003_PROC_CODE] = "000000";
isoMessage[Iso8583.Bit._011_SYS_TRACE_AUDIT_NUM] = "000001";
isoMessage[Iso8583.Bit._041_CARD_ACCEPTOR_TERMINAL_ID] = "29110001";
I know this is tricky, because some fields are BCD, AlpahNumeric, Numeric, etc. however, this should be realively easy (or I would think) using OpenIso8583.Net? The result I'd like to get is:
Msg Bitmap (3, 11, 41) ProcCode Audit Terminal ID
----- ----------------------- -------- -------- -----------------------
08 00 20 20 00 00 00 80 00 00 00 00 00 00 00 01 32 39 31 31 30 30 30 31
Any help would be greatly appreciated!
Essentially, you need to extend Iso8583 which you initialise with your own Template In the Template, you can set the formatters for each field so that BCD and binary packing is not used. Have a look at the source code for Iso8583 as to how it works.
I am beta testing an application that includes a Firefox extension as one component. It was originally deployed when FF3.5.5 was the latest version, and survived 3.5.6 and 3.5.7. However on FF3.6 I'm getting the following in my error console:
Warning: reference to undefined property Components.interfaces.nsIProcess2
Source file: chrome://overthewall/content/otwhelper.js
Line: 55
Error: Component returned failure code: 0x80570018 (NS_ERROR_XPC_BAD_IID)
[nsIJSCID.createInstance]
Source file: chrome://overthewall/content/otwhelper.js
Line: 55
The function throwing the error is:
48 function otwRunHelper(cmd, aCallback) {
49 var file =
50 Components.classes["#mozilla.org/file/local;1"].
51 createInstance(Components.interfaces.nsILocalFile);
52 file.initWithPath(otwRegInstallDir+'otwhelper.exe');
53
54 otwProcess = Components.classes["#mozilla.org/process/util;1"]
55 .createInstance(Components.interfaces.nsIProcess2);
56
57 otwProcess.init(file);
58 var params = new Array();
59 params = cmd.split(' ');
60
61 otwNextCallback = aCallback;
62 otwObserver = new otwHelperProcess();
63 otwProcess.runAsync(params, params.length, otwObserver, false);
64 }
As you can see, all this function does is run an external EXE helper file (located by a registry key) with some command line parameters and sets up an Observer to asynchronously wait for a response and process the Exit code.
The offending line implies that Components.interfaces.nsIProcess2 is no longer defined in FF3.6. Where did it go? I can't find anything in the Mozilla documentation indicating that it has been changed in the latest release.
The method on nsIProcess2 was moved to nsIProcess. For your code to work in both versions, change this line:
otwProcess = Components.classes["#mozilla.org/process/util;1"]
.createInstance(Components.interfaces.nsIProcess2);
to this:
otwProcess = Components.classes["#mozilla.org/process/util;1"]
.createInstance(Components.interfaces.nsIProcess2 || Components.interfaces.nsIProcess);
You will still get the warning, but the error will go away, and your code will work just fine in both versions. You could also store the interface iid in a variable and use the variable:
let iid = ("nsIProcess2" in Components.interfaces) ?
Components.interfaces.nsIProcess2 :
Components.interfaces.nsIProcess;
otwProcess = Components.classes["#mozilla.org/process/util;1"]
.createInstance(iid);