I'm using cmder (/ConEmu) on Windows 10, and child_process.execFileSync is returning an Uint8Array instead of a String. Resulting in a fixed console width of 80 columns; the fallback width, as the array doesn't have a trim method.

Fixed this by forcing the response to become a string, before calling the trim method.

I am working on a product that distributes node and npm as a dependency for an application, which revealed that the 'term-size' MacOS binary is not signed. As 'term-size' is a dependency of npm (a transitive dependency inside boxen which is inside of update-notifier), it would be good for the distributed binary to be codesigned by the entity that makes the binary.

The current workaround is to codesign it ourselves.

I had a similar idea, to read the columns using tput 'cols' for that matter, but still, the child process, does not have any knowledge of the parent window width, hence it does not quite work, it cannot be used to reliably get the window width, as you can see below.

Looking at the above, the tests should not have passed. Sizes are different.

I'm seeing this error when process.env.TERM is undefined and process.stdout.isTTY is undefined.

tput: No value for $TERM and no -T specified

It happens on line 60 when tput cols is executed.

https://github.com/sindresorhus/term-size/blob/92aa07ee3a1cc28360af1c908f8a2ae10b6552bd/index.js#L60

https://github.com/sindresorhus/execa/compare/v0.7.0...v0.8.0

Nothing affects term-size, but this update helps better deduplication for the project using the latest execa.

I'm bundling term-size using esbuild, which handles import.meta.url a bit differently than other bundlers.

Now, in my case, the fileURLToPath call is dead code, because I'm running my bundle on Linux, where term-size doesn't need to invoke any commands. So I was thinking it could be more lazy, and coincidentally fix the issue I'm facing.

This PR moves the __dirname emulation into a helper function that's only called on macOS and Windows.

I've also put the line-splitting in there because I prefer DRY code, but it's a bit esoteric this way. Would you prefer an explicit splitLines (or even a dependency on split-lines)? Or alternatively, I could make a less invasive PR and only extract the __dirname construction into a helper function, for example.

... Or we could find a better way to deal with the lack of __dirname in ESM. 😉

When using term-info on a non-interactive terminal (like in CI or a pre-commit hook in Sublime Merge), resize and tput write out to stderr:

Opening `/dev/tty` failed (6): Device not configured
resize:  can't open terminal /dev/tty
tput: No value for $TERM and no -T specified

We can suppress these by passing 'ignore' for the third tuple value of stdio, which corresponds to stderr.

2.2.0 has a bunch of .DS_Store files in the vendor subdirectory. https://unpkg.com/browse/[email protected]/vendor/

Publishing from a newer npm version should not include them, but in case they are included you can add a .npmignore file in the vendor subdirectory and add .DS_Store

I'd like to be able to rebuild vendor/resize binary for the debian package. Or can I skip that binary if I only wanted to be able to use term-size from ava.

Ref: https://github.com/sindresorhus/macos-term-size/pull/3/ Ref: https://github.com/nodejs/node/pull/31459

$ codesign -dv vendor/macos/term-size
Executable=/Users/rvagg/git/term-size/vendor/macos/term-size
Identifier=term-size
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=277 flags=0x10000(runtime) hashes=3+2 location=embedded
Signature size=8986
Timestamp=30 Jan 2020 at 9:29:23 pm
Info.plist=not bound
TeamIdentifier=HX7739G8FX
Runtime Version=10.14.0
Sealed Resources=none
Internal requirements count=1 size=172

Have also tested the binary on a 10.10 machine and it's :thumbsup:.

(for puzzled onlookers: this is being done because this is bundled with npm and we need to notarize our packages which includes having all executable binaries signed)

• Replaced “execa” with the native “child_process” module.
• Imported “strip-eof” directly.

I tested this manually as the provided tests won't hit the lines I changed, and they will basically always pass anyway since this library always provides a fallback size.

Hey there,

could you add support for the Git Bash console (that you get by default when installing on Windows)? Getting the size has basically been done (I shamelessly stole most of this from here, around line 90)

const {execSync} = require('child_process');
var buf = execSync('tput cols && tput lines', {stdio: ['ignore', 'pipe', process.stderr]});
var sz = buf.toString().trim().split('\n');
if(sz && sz.length == 2){
    return create(sz[0], sz[1]);
}

I can create a PR if you want, however I'm not really a js-dev, so you might want to do this yourself.

Hi, is it possible to eliminate the exe file inside the package? https://registry.npmjs.org/term-size/-/term-size-2.1.1.tgz because of this our organization it security web filtering block access to this module and it causes us a lot of trouble.

I can't print the output to stdout, because its redirected :-), so I use the exit status.

Tested on Linux with node >= 6.x. Also tried rows. I'd expect this to be ancient unix behaviour shared with OS X.

core/node (master $ u=) % node -p 'require("tty").WriteStream(require("fs").openSync("/dev/tty", "w")).columns'     
174
core/node (master $ u=) % node -p 'process.exit(require("tty").WriteStream(require("fs").openSync("/dev/tty", "w")).columns)' < /dev/null >/dev/null 2>/dev/null; echo $?
174
core/node (master $ u=) % nvm run 13 -p 'process.exit(require("tty").WriteStream(require("fs").openSync("/dev/tty", "w")).columns)' < /dev/null >/dev/null 2>/dev/null; echo $?
174
core/node (master $ u=) % nvm run 12 -p 'process.exit(require("tty").WriteStream(require("fs").openSync("/dev/tty", "w")).columns)' < /dev/null >/dev/null 2>/dev/null; echo $?
174
core/node (master $ u=) % nvm run 10 -p 'process.exit(require("tty").WriteStream(require("fs").openSync("/dev/tty", "w")).columns)' < /dev/null >/dev/null 2>/dev/null; echo $?
174
core/node (master $ u=) % nvm run 8 -p 'process.exit(require("tty").WriteStream(require("fs").openSync("/dev/tty", "w")).columns)' < /dev/null >/dev/null 2>/dev/null; echo $?

174
core/node (master $ u=) % nvm run 6 -p 'process.exit(require("tty").WriteStream(require("fs").openSync("/dev/tty", "w")).columns)' < /dev/null >/dev/null 2>/dev/null; echo $?

174

Node.js, or rather V8, is planning native FFI support. This would be much better than spawning binaries.

Just for reference, I can't use node-ffi today as it's a native addon and that comes with too many headaches.

So trying to fix this issue I found that in this line of term-size stops the execution:

const size = execa.sync('resize', ['-u']).stdout.match(/\d+/g);

Reproduce

With the vendor/resize binary, execute a script:

#!/usr/bin/env node
const path = require('path')
const execa = require('execa')
const size = execa.shellSync(path.join(__dirname, 'resize'), ['-u']).stdout.match(/\d+/g)
console.log(size)

And executing like this:

$ ./index.js >log.txt 2>&1 &
[2] 15736
[2]  + 15736 suspended (tty output)  ./index.js > log.txt 2>&1
$ cat log.txt

$ 

This doesn't happen when you don't run the process in the background (so, without the last &):

$ ./index.js >log.txt 2>&1
$ cat log.txt
[ '111', '25' ]
$

This could be an error in execa or in the resize binary, I have no clue.