Httpie hangs in Git Bash terminal on Windows 10 - httpclient

According to the official documentation httpie tool also works on Windows 10, however when I run the command in terminal it simply hangs and nothing happens:
$ http :8000/
Is there an explanation what is going on and preferably a workaround?

I was able to get a hint by appending the --debug parameter:
$ http localhost:8000 --debug
HTTPie 0.9.9
Requests 2.12.4
Pygments 2.1.3
Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 20:20:57) [MSC v.1600 64 bit (AMD64)]
c:\users\...\venv\scripts\python.exe
Windows 10
<Environment {
"colors": 256,
"config": {
"__meta__": {
"about": "HTTPie configuration file",
"help": "https://httpie.org/docs#config",
"httpie": "0.9.9"
},
"default_options": "[]"
},
"config_dir": "C:\\Users\\...\\AppData\\Roaming\\\\httpie",
"is_windows": true,
"stderr": "<colorama.ansitowin32.StreamWrapper object at 0x0000000003CDAB00>",
"stderr_isatty": false,
"stdin": "<_io.TextIOWrapper name='<stdin>' mode='r' encoding='cp1252'>",
"stdin_encoding": "cp1252",
"stdin_isatty": false,
"stdout": "<colorama.ansitowin32.StreamWrapper object at 0x0000000003CDA9B0>",
"stdout_encoding": "cp1252",
"stdout_isatty": false
}>
The crucial point is that the isatty related option is set to false.
I was able to resole it and getting http working as expected by prepending the winpty command:
$ winpty http :8000
HTTP/1.0 200 OK
Content-Type: application/json
Date: Fri, 16 Dec 2016 19:56:58 GMT
Server: WSGIServer/0.2 CPython/3.4.4
X-Frame-Options: SAMEORIGIN
{
"status": "ok"
}
Solution:
By adding this alias line
alias http='winpty http'
to the ~/.profile file, one can use the initial command http as expected with git bash.

Related

openocd only runs in msys64 shell (and not from vscode debug)

I am trying to debug a raspberry pi pico from vscode using a picoprobe. After a lot of pain I managed to get everything running from a msys2 mingw64 shell (I built openocd in that shell). However, debugging from vscode results in a popup saying OpenOCD: GDB Server Quit Unexpectedly. My Debug console reads
Cortex-Debug: VSCode debugger extension version 1.6.7 git(b0f5563). Usage info: https://github.com/Marus/cortex-debug#usage
Reading symbols from arm-none-eabi-objdump --syms -C -h -w C:/VSARM/sdk/pico/pico-examples/build/blink/blink.elf
Reading symbols from arm-none-eabi-nm --defined-only -S -l -C -p C:/VSARM/sdk/pico/pico-examples/build/blink/blink.elf
Launching GDB: arm-none-eabi-gdb -q --interpreter=mi2
1-gdb-version
Launching gdb-server: "C:/VSARM/debug_tools/openocd/src/openocd.exe" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "C:V/SARM/debug_tools/openocd/tcl" -f "c:/Users/micha/.vscode/extensions/marus25.cortex-debug-1.6.7/support/openocd-helpers.tcl" -f interface/cmsis-dap.cfg -f target/rp2040.cfg
Please check TERMINAL tab (gdb-server) for output from C:/VSARM/debug_tools/openocd/src/openocd.exe
Finished reading symbols from objdump: Time: 86 ms
Finished reading symbols from nm: Time: 115 ms
OpenOCD: GDB Server Quit Unexpectedly. See gdb-server output in TERMINAL tab for more details.
and my terminal (set to msys2 mingw64 terminal in the vscode settings) reads
[2022-12-05T14:08:43.239Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
"C:/VSARM/debug_tools/openocd/src/openocd.exe" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "C:V/SARM/debug_tools/openocd/tcl" -f "c:/Users/micha/.vscode/extensions/marus25.cortex-debug-1.6.7/support/openocd-helpers.tcl" -f interface/cmsis-dap.cfg -f target/rp2040.cfg
[2022-12-05T14:08:43.310Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...
My launch.json is
{
"version": "0.2.0",
"configurations": [
{
"name": "Pico Debug",
"cwd": "${workspaceRoot}",
"executable": "${command:cmake.launchTargetPath}",
"request": "launch",
"type": "cortex-debug",
"servertype": "openocd",
// This may need to be arm-none-eabi-gdb depending on your system
"gdbPath" : "arm-none-eabi-gdb",
"device": "RP2040",
"configFiles": [
"interface/cmsis-dap.cfg",
"target/rp2040.cfg"
],
"svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd",
"runToMain": true,
// Work around for stopping at main on restart
"postRestartCommands": [
"break main",
"continue"
],
"searchDir": ["C:/VSARM/debug_tools/openocd/tcl"],
"showDevDebugOutput": "raw",
}
]
}
Does somebody see a mistake in my setup?
Currently, my best guess is that there is some sort of dependency that is only satisfied in msys2 mingw64 and not in the terminal (windows power shell?) vscode uses to run the gdb/openocd server.
Does somebody know how I can force vscode (or the cortex-debug extension) to use the msys2 mingw64 shell to run openocd?
An other possible solution/workaround I see is to start the openocd server manually in msys2 mingw64. I could then connect to the openocd server from vscode. Does somebody know if and how I can do this? I only found solutions where vscode starts both the gdb and openocd server.
Thank you for your help.

Perl 5.26 on RHEL 7 error - cgi-error - libperl.so.rh-perl526-5.26: cannot open shared object file

I am attempting to run perl CGI script on RHEL 7, i've used yum installer and it's successfully installed 5.26, i can run perl programs from terminal without problem, but when i run a simple CGI script it writes error to httpd/error.log. I've posted the exact error below.
enabled software collection
$scl enable rh-perl526 bash
perl -v
This is perl 5, version 26, subversion 3 (v5.26.3) built for x86_64-linux-thread-multi
(with 27 registered patches, see perl -V for more detail)
$which perl
/opt/rh/rh-perl526/root/usr/bin/perl
$perl -e 'print "Hello Perl\n"'
Hello Perl
When i run a simple CGI script from browser or curl -XGET, i got 500 internal server for
http://serverip/cgi-bin/test-cgi.pl
apache error
[Wed Mar 24 21:24:38.308033 2021] [cgi:error] [pid 9437] [client x.x.x.x:35220] AH01215: /opt/rh/rh-perl526/root/usr/bin/perl: error while loading shared libraries: libperl.so.rh-perl526-5.26: cannot open shared object file: No such file or directory
[Wed Mar 24 21:24:38.308245 2021] [cgi:error] [pid 9437] [client x.x.x.x:35220] End of script output before headers: test.cgi.pl
I've added libperl.so path to LD_LIBRARY_PATH variable in .bashrc and i've rh-perl526-perl-libs.x86_64 package installed.
While installing rh-perl526, i noticed it also installed default perl on system as well due to YUM dependency
any idea how to fix this issue ?
LD_LIBRARY_PATH needs to set in apache http.conf file
i have added below line in httpd.conf and it worked
SetEnv LD_LIBRARY_PATH /path/to/libperl
I also removed perl 5.16 from system using yum.

How to correctly display messages in console?

I use mojolicious application. When I do logging all if fine, except when I run application under morbo I see text like:
$app->log->info('тест лога');
[Sat Oct 6 15:22:43 2018] [info] �е�� лога
here is some problem with utf8.
What should I do that messages will be correctly displayed?
My terminal have support for utf8. I run Linux Mint v19.3
Here is how messages looks which come from script:
Test terminal:
Don't use the following when using Mojo::Log to write to STDERR:
binmode STDERR, ':encoding(UTF-8)';
Mojo::Log explicitly encodes everything it logs using UTF-8, even when writing to STDERR.
sub append {
my ($self, $msg) = #_;
return unless my $handle = $self->handle;
flock $handle, LOCK_EX;
$handle->print(encode('UTF-8', $msg)) or croak "Can't write to log: $!";
flock $handle, LOCK_UN;
}
When using STDERR as the log output (the default), this conflicts with the well-established practice of adding an encoding layer to STD*. In such a circumstance, double-encoding occurs.
One must therefore avoid doing
binmode STDERR, ':encoding(UTF-8)';
Note that this is done as part of
use open ':std', ':encoding(UTF-8)';
Try to run following code sample in your system. The test confirmed with correct UTF-8 output in terminal
#!/usr/bin/env perl
use Mojolicious::Lite -signatures;
get '/' => sub ($c) {
$c->render(text => 'Hello World!');
};
app->log->info('тест лога');
app->start;
Run as morbo test.pl produces following output
:u99257852:~/work/perl/mojo$ morbo ./test.pl
Web application available at http://127.0.0.1:3000
[2020-10-31 13:33:57.42056] [83940] [info] тест лога
[2020-10-31 13:35:16.72465] [83940] [debug] [hga9Tgyy] GET "/"
[2020-10-31 13:35:16.72528] [83940] [debug] [hga9Tgyy] Routing to a callback
[2020-10-31 13:35:16.72574] [83940] [debug] [hga9Tgyy] 200 OK (0.001078s, 927.644/s)
(uiserver):u99257852:~/work/perl/mojo$
Tested locally with nc localhost 3000
(uiserver):u99257852:~$ nc localhost 3000
GET / HTTP/1.1
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2020 17:35:16 GMT
Server: Mojolicious (Perl)
Content-Type: text/html;charset=UTF-8
Content-Length: 12
Hello World!
Output of uname -a
(uiserver):u99257852:~/work/perl/mojo$ uname -a
Linux infongwp-us19 4.4.223-icpu-044 #2 SMP Sun May 10 11:26:44 UTC 2020 x86_64 GNU/Linux
(uiserver):u99257852:~/work/perl/mojo$
Bash is user's shell configured with ~/.bashrc with following settings to support UTF-8
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8:

Protractor tests are not running in gitlab-ci after Google Chrome updated to version 75 yesterday. It worked before the update. What happened?

I am running a scheduled job in gitlab to run protractor tests on an application on Google Chrome. These tests were working along nicely until yesterday June 04, 2019 where Google updated chrome from version 74 to version 75. Now I am getting a "W/launcher - Ignoring uncaught error WebDriverError: Unable to parse new session response" issue since the update.
This is run on the gitlab ci environment. I don't use webdriver-manager, my team really needs me to use docker-compose to create a selenium grid. I don't really know where to start fixing this issue.
test:
stage: test
before_script:
- apk add py-pip
- pip install --upgrade pip
- pip install docker-compose==1.23.2
- docker login -u $DOCKERHUB_REGISTRY_USER -p $DOCKERHUB_REGISTRY_PASSWORD
- echo "//registry.npmjs.org/:_authToken=\${NPM_HAVENBUILD_AUTH_TOKEN}" > .npmrc
- npm install
- npm config set unsafe-perm true
- npm install -g protractor
- npm install -g protractor-console
- npm config set unsafe-perm falsesh
- ./node_modules/.bin/gulp
script:
- docker-compose up -d
- docker-compose scale chrome=2
- ./node_modules/.bin/protractor TestFiles/HConf.js --suite client --testname Happy_Path --env uat
This is the error I am getting:
[19:53:28] I/hosted - Using the selenium server at http://docker-dind:4444/wd/hub
[19:53:28] W/launcher - Ignoring uncaught error WebDriverError: Unable to parse new session response: {
"value": {
"sessionId": "d8b6ab9a6e301a943203e8af49aec285",
"capabilities": {
"acceptInsecureCerts": false,
"browserName": "chrome",
"browserVersion": "75.0.3770.80",
"chrome": {
"chromedriverVersion": "75.0.3770.8 (681f24ea911fe754973dda2fdc6d2a2e159dd300-refs\u002fbranch-heads\u002f3770#{#40})",
"userDataDir": "\u002ftmp\u002f.com.google.Chrome.zQzfpf"
},
"goog:chromeOptions": {
"debuggerAddress": "localhost:46326"
},
"networkConnectionEnabled": false,
"pageLoadStrategy": "normal",
"platformName": "linux",
"proxy": {
},
"setWindowRect": true,
"strictFileInteractability": false,
"timeouts": {
"implicit": 0,
"pageLoad": 300000,
"script": 30000
},
"unhandledPromptBehavior": "dismiss and notify",
"webdriver.remote.sessionid": "d8b6ab9a6e301a943203e8af49aec285"
}
}
}
[19:53:28] E/launcher - BUG: launcher exited with 1 tasks remaining
I am suppose to have the protractor tests run insead of this after it starts using the selenium server.
Does anyone know what the issue is?

Swift TempAuth returned 404 when HEAD the account

I am a newbie to Swift, but was trying to install it on my CentOS 6.5 VM. I have done
Installing lasted Swift release (1.12.0) and python-swiftclient (2.0.2) and their dependencies
Preparing and mounting my drive (a separated device formated as xfs) at /svr/node/d1
Creating the rings and adding the device to the rings (account, container, object)
Building the rings, which generates one .ring.gz file for each ring. Placed them in /etc/swift
Configuring hash_path_prefix for proxy
Setting up TempAuth and adding a new user 'myaccount:me' with password 'pa'
Starting proxy and account.
I would expect to successfully do
swift -A http://localhost:8080/auth/v1.0 -U myaccount:me -K pa stat
but the command told me 'Account not found'. To see detailed information, I did
swift --debug -v -A http://localhost:8080/auth/v1.0 -U myaccount:me -K pa stat
the output is
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): localhost
DEBUG:requests.packages.urllib3.connectionpool:"GET /auth/v1.0 HTTP/1.1" 200 0
DEBUG:swiftclient:REQ: curl -i http://localhost:8080/auth/v1.0 -X GET
DEBUG:swiftclient:RESP STATUS: 200 OK
DEBUG:swiftclient:RESP HEADERS: [('content-length', '0'), ('x-trans-id', 'tx88b6b6b71ec14c3393248-00530de039'), ('x-auth-token', 'AUTH_tkdc7e842046e9469da324f2ec82c80a92'), ('x-storage-token', 'AUTH_tkdc7e842046e9469da324f2ec82c80a92'), ('date', 'Wed, 26 Feb 2014 12:38:17 GMT'), ('x-storage-url', 'http://localhost:8080/v1/AUTH_myaccount'), ('content-type', 'text/html; charset=UTF-8')]
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): localhost
DEBUG:requests.packages.urllib3.connectionpool:"HEAD /v1/AUTH_myaccount HTTP/1.1" 404 0
INFO:swiftclient:REQ: curl -i http://localhost:8080/v1/AUTH_myaccount -I -H "X-Auth-Token: AUTH_tkdc7e842046e9469da324f2ec82c80a92"
INFO:swiftclient:RESP STATUS: 404 Not Found
INFO:swiftclient:RESP HEADERS: [('date', 'Wed, 26 Feb 2014 12:38:17 GMT'), ('content-length', '0'), ('content-type', 'text/html; charset=UTF-8'), ('x-trans-id', 'tx553c40e63c69470e9d146-00530de039')]
ERROR:swiftclient:Account HEAD failed: http://localhost:8080:8080/v1/AUTH_myaccount 404 Not Found
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/swiftclient/client.py", line 1192, in _retry
rv = func(self.url, self.token, *args, **kwargs)
File "/usr/lib/python2.6/site-packages/swiftclient/client.py", line 469, in head_account
http_response_content=body)
ClientException: Account HEAD failed: http://localhost:8080:8080/v1/AUTH_myaccount 404 Not Found
Account not found
I figured out my self: in proxy-server.conf, add these two lines
allow_account_management = true
account_autocreate = true