entrez / beluga-cli Goto Github PK

when certain files (for example, some binary files - I noticed it with Across Lite .puz binary files) are moved or copied from one cdn:// destination to another, the following error is displayed:

beluga-cli: line 821: warning: command substitution: ignored null byte in input

the resulting file is corrupted, apparently a result of the file only being copied up to the first null byte. presumably any file which contains internal null byte(s) would cause this problem.

unexpected flags starting with two dashes (--flag) should be treated as a single word, not as individual flags. currently, running beluga-cli <cmd> --flag will return "unexpected flags -flag" (even worse, if any of the letters are acceptable flags, they will be interpreted as such, so trying to run beluga-cli <cmd> --testflag will not produce any error output, because -s flag behavior will be activated).

if the .defaults file has an invalid checksum, beluga-cli displays the following error message before exiting:

error: config file checksum invalid
run beluga-cli setup to set up a new defaults file, or beluga-cli help for more information.

however, the if statement which causes this behavior comes before any testing of the arguments included by the user, including checking whether the user is running beluga-cli setup. this means that once you have an invalid config file, you're stuck with it until you manually fix or delete the .defaults file (which may be quite difficult if you don't know where it is).

running the command beluga-cli help -s causes a broken help page

some of the usage prompt text (seemingly the stuff formatted like [-x|--example <foo>] or similar) is misinterpreted by bash as references to items in the current directory and/or as mathematical statements which should be evaluated before display.

not only does this cause issues with delivering usage/help info in some circumstances (where parts of the help text are not displayed properly) but also seems like it could potentially have unintended side-effects that impact the files being ``referred to''.

The script currently uses a single, hardcoded temp file in its config directory for storing a remote file temporarily on the local machine, without checking the current status of the file or anything of the sort. This means that if one beluga-cli process is in the middle of doing something, and the user runs a similar command in another terminal session/window/tab, the file will be overwritten by session 2.

the way the behavior, and more specifically the output formatting, of openssl differs between bash and cygwin (or at least this seems to me to be the cause; it could also be some other issue, like an inadvertant difference in configurations that I haven't noticed) leads to issues with interpreting and verifying the md5 checksums used for verifying the integrity of config files.

bash 4.4 on mac osx:

$ echo -ne "hello" | openssl md5
5d41402abc4b2a76b9719d911017c592

cygwin:

$ echo -ne "hello" | openssl md5
(stdin)= 5d41402abc4b2a76b9719d911017c592

the extra space between (stdin)= and the actual output breaks the code which attempts to verify the checksum, since it relies on $IFS to divide the file on a consistent, line-by-line basis, causing any command to result in the "error: config file checksum invalid" even when defaults have been set up correctly.

when I attempt to run beluga-cli cp ~/Documents/folder\ with\ spaces/file.png cdn://file.png, or a similar command where the path contains spaces, beluga-cli returns the following error: illegal input: input [beluga-cli cp ~/Documents/folder\ with\ spaces/file.png cdn://file.png] contains no cdn:// uri

Local paths starting with ../ (i.e. a path starting one directory above the pwd) are not interpreted correctly.

example:

$ pwd
/Users/entrez/Downloads/testdir
$ test -f ../test-file.txt; echo $?
0
$ beluga-cli cp ../test-file.txt cdn://test
failed: /Users/entrez/Downloads/testdir/ -> http://cdn.example.com/test/
is a directory: /Users/entrez/Downloads/testdir/

It seems like the local path is being replaced with $PWD entirely, rather that being interpreted as it should be.

noticed this because api.belugacdn.com seem to be down, or at least having intermittent problems. requests i make to api.belugacdn.com seem to be producing 504 response codes 75% of the time or more.

under the current circumstances, an example of the output of beluga-cli iv is as follows:

michael@rain [1-31-19] > beluga-cli iv cdn://comedy/media.rss
invalidating: http://cdn.example.com/comedy/media.rss
/usr/local/bin/beluga-cli: line 338: [[: 15
16: syntax error in expression (error token is "16")
request
/usr/local/bin/beluga-cli: line 338: [[: 7
24: syntax error in expression (error token is "24")
<html>
<head><title>504
/usr/local/bin/beluga-cli: line 338: [[: 32
5: syntax error in expression (error token is "5")
Gateway
/usr/local/bin/beluga-cli: line 338: [[: 24
21
15: syntax error in expression (error token is "21
15")
Time-out</title></head>
<body
/usr/local/bin/beluga-cli: line 338: [[: 15
23: syntax error in expression (error token is "23")
bgcolor=white>
<center><h1>504
/usr/local/bin/beluga-cli: line 338: [[: 31
34
8
8: syntax error in expression (error token is "34
8
8")
Gateway
Time-out</h1></center>
<hr><center>nginx/1.12.2</center>
</body>
</html>

it's clear that the 504 response (and the actual page which is displayed to indicate a 504 response) is in there somewhere, but it's causing the script to crash and burn for some reason.

mv would probably be more efficient if it discriminated between moving items from one location to another vs renaming a remote item, using ftp rename operation(s) for the latter if supported by the target server.

maybe this should be something done automatically under certain circumstances when mv is used, maybe it should be a different command entirely?

when i navigate to a directory on an external volume, eject and reconnect it, and run beluga-cli i get the following error:
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

so far this has just been an error message that hasn't impacted the actual (remote) operation being performed, but i'd guess that may not be the case when working with local files.

i assume this would happen in any directory which has been deleted and recreated since navigating there.

i'm not sure how/whether using $PWD (which I think should always be defined, at least in theory) instead of getcwd would potentially impact this behavior but it might be something to consider.