require errors show private instead of actual file path - node.js

Today I got surprised by the following (you can try at node repl):
require("/tmp/bad.json")
SyntaxError: /private/tmp/bad.json: Unexpected token n in JSON at position 3
As you can see, I required (intentionally) a JSON file that contains a syntax error. However, on the error message, instead of the actual file path, which starts at '/tmp/' you can see that it has been replaced by the string /private/.
Why is this?
I'm using node v8.15.0

This has nothing to do with Node or the node version but with the operating system. In this case, I was using OSX, where /tmp is just a symbolic link to /private/tmp. Then when the error was triggered the actual path is showing.

Related

folder path with space giving error in subprocess.call

drivesToMap = ["R: \\\\server1\folder", "G: \\\\server1\folder withSpace"]
for eachDrive in drivesToMap:
call("net use " + eachDrive)
In python 3 on a windows 10 machine I am getting the following error for the code above :
System error 1232 has occurred.
The network location cannot be reached. For information about network troubleshooting, see Windows Help.
How do I resolve the space? When I type in the command from a doc cmd it works succussfully:
net use G: \server1\folder withSpace
You likely need to wrap the drive in an additional set of quotes, since net use is a command prompt command it is anticipating that the drive name (which has spaces) is actually multiple arguments instead of one.
For instance:
drivesToMap = ["'R: \\\\server1\folder'", "'G: \\\\server1\folder withSpace'"]

TypeScript "Could not find a declaration file" error on some Node.js versions

I'm trying to set the "noImplicitAny": true option for an existing TypeScript project. After making all the necessary code changes I'm getting the following error for one of our dependencies on Node 6 and 7:
Could not find a declaration file for module '#firebase/database'. '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js' implicitly has an 'any' type.
This works fine on Node 8 (both locally and on Travis CI).
Does anybody know why this is? I can kind of understand the error, but no clue why it happens only on certain versions of Node.
Edit
Added the traceResolution option, and I do see a difference in how the dependency gets resolved between Node 7 and 8.
On Node 8:
'package.json' has 'typings' field 'dist/index.d.ts' that references '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts'.
File '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts' exist - use it as a name resolution result.
Resolving real path for '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts', result '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts'.
======== Module name '#firebase/database' was successfully resolved to '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts'. ========
On Node 7:
'package.json' has 'typings' field 'dist/index.d.ts' that references '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts'.
File '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts' does not exist.
Loading module as file / folder, candidate module location '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts', target file type 'TypeScript'.
File '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.d.ts.ts' does not exist.
...
File '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js' exist - use it as a name resolution result.
Resolving real path for '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js', result '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js'.
======== Module name '#firebase/database' was successfully resolved to '/home/travis/build/firebase/firebase-admin-node/node_modules/#firebase/database/dist/index.node.cjs.js'. ========

Win10: ASDF can't load system (ASDF_OUTPUT_TRANSLATION error)

Update 2
I think #faré is right, it's an output translation problem.
So I declared the evironment variable ASDF_OUTPUT_TRANSLATIONS and set it to E:/. Now (asdf:require-system "my-system") yields a different error: Uneven number of components in source to destination mapping: "E:/" which led me to this SO-topic.
Unfortunately, his solution doesn't work for me. So I tried the other answer and set ASDF_OUTPUT_TRANSLATIONS to (:output-translations (t "E:/")). Now I get yet another error:
Invalid source registry (:OUTPUT-TRANSLATIONS (T "E:/")).
One and only one of
:INHERIT-CONFIGURATION or
:IGNORE-INHERITED-CONFIGURATION
is required.
(will be skipped)
Original Posting
I have a simple system definition but can't get ASDF to load it.
(asdf-version 3.1.5, sbcl 1.3.12 (upgraded to 1.3.18 AMD64), slime 2.19, Windows 10)
What I have tried so far
Following the ASDF manual: "4.1 Configuring ASDF to find your systems"
There it says:
For Windows users, and starting with ASDF 3.1.5, start from your
%LOCALAPPDATA%, which is usually ~/AppData/Local/ (but you can ask in
a CMD.EXE terminal echo %LOCALAPPDATA% to make sure) and underneath
create a subpath config/common-lisp/source-registry.conf.d/
That's exactly what I did:
Echoing %LOCALAPPDATA% which evaluates to C:\Users\my-username\AppData\Local
Underneath I created the subfolders config\common-lisp\source-registry.conf.d\ (In total: C:\Users\my-username\AppData\Local\config\common-lisp\source-registry.conf.d\
The manual continues:
there create a file with any name of your choice but with the type conf, for instance 50-luser-lisp.conf; in this file, add the following line to tell ASDF to recursively scan all the subdirectories under /home/luser/lisp/ for .asd files: (:tree "/home/luser/lisp/")
That’s enough. You may replace /home/luser/lisp/ by wherever you want to install your source code.
In the source-registry.conf.d folder I created the file my.conf and put in it (:tree "C:/Users/my-username/my-systems/"). This folder contains a my-system.asd.
And here comes the weird part:
If I now type (asdf:require-system "my-system") in the REPL I get the following error:
Can't create directory C:\Users\my-username\AppData\Local\common-lisp\sbcl-1.3.12-win-x86\C\Users\my-username\my-systems\C:\
So the problem is not that ASDF doesn't find the file, it does -- but (whatever the reason) it tries to create a really weird subfolder hierarchy which ultimately fails because at the end it tries to create the folder C: but Windows doesn't allow foldernames containing a colon.
Another approach: (push path asdf:*central-registry*)
If I try
> (push #P"C:/Users/my-username/my-systems/" asdf:*central-registry*)
(#P"C:/Users/my-username/my-systems/"
#P"C:/Users/my-username/AppData/Roaming/quicklisp/quicklisp/")
> (asdf:require-system "my-system")
I get the exact same error.
I don't know what to do.
Update
Because of the nature of the weird path ASDF was trying to create I thought maybe I could bypass the problem by specifying a relative path instead of an absolute one.
So I tried
  (:tree "\\Users\\my-username\\my-systems")
in my conf file. Still the same error.
Ahem. It looks like an output-translations problem.
I don't have a Windows machine right now, but this all used to work last time I tried.
Can you setup some ad hoc output-translations for now that will make it work?

URLWatch: Using urls.yaml from a remote URL

I am trying to update my current urlwatch.py file with the ability to call the urls.yaml file from a remote server. I've tried to modify the urls_yaml variable with the URL I would like to use without any luck. (Generic URL is being used for the example):
urls_yaml = 'http://pathtourl.com/urls.yaml')
The standard output message is:
You need to create http://pathtourl.com/urls.yaml in order to use urlwatch.
Use "urlwatch --edit" to open the file with your editor.
The error message is:
File "/Users/mattstone/Python/urlwatch-2.2/urlwatch", line 51
urls_yaml = 'http://pathtourl.com/urls.yaml')
^
SyntaxError: invalid syntax
In the above standard output, I'm confused on how I would create the yaml on a remote server when it's not installed there.

Lua: error loading module file not found

I'm trying to set up Lighttpd + lua + fastcgi to run web interface on an embedded MIPS board. But the important part here, I guess is Lua.
When trying to run /usr/local/bin/wsapi.fcgi (which is lua script) I get this error:
/usr/bin/lua: error loading module 'lfcgi' from file '/usr/local/lib/lua/5.1/lfcgi.so':
File not found
stack traceback:
[C]: ?
[C]: in function 'require'
/usr/local/share/lua/5.1/wsapi/fastcgi.lua:9: in main chunk
[C]: in function 'require'
/usr/local/bin/wsapi.fcgi:9: in main chunk
[C]: ?
Which is really strange, because ls shows that file is there and all permissions are ok:
# ls -l /usr/local/lib/lua/5.1/lfcgi.so
-rwxr-xr-x 1 0 0 21152 /usr/local/lib/lua/5.1/lfcgi.so
And which is more frustrating, if I actually remove the file, lua shows a different error, which means that first error wasn't really caused by lua unable to locate file properly.
So I'm a bit lost here, looks like the error message is misleading and problem isn't really the file being not found, but what...
P.S. The error comes from file wsapi/fastcgi.lua, from line 9 which looks like this:
local lfcgi = require"lfcgi"
- maybe there is something wrong with require syntax? I'm no expert in lua so I can't tell.
Ok, I figured it out. It turned out to be a missing dependency, as #Ctx suggested.
readelf -d lfcgi.so | grep NEEDED
shows that it needs libfcgi.so.0 which is a symlink to libfcgi.so and I only have the last one, not the symlink.
After creating the symlink it is working now (actually it comes with another error, but it is a different story :P).
By the way - the error message is really confusing - it looks like the file lfcgi.so is missing, when in fact it is one of its dependencies that is causing the problem.

Resources