Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to disable call to clear #58

Closed
insidewhy opened this issue May 6, 2020 · 12 comments
Closed

Add option to disable call to clear #58

insidewhy opened this issue May 6, 2020 · 12 comments

Comments

@insidewhy
Copy link

I run sirv with other processes via concurrently.

When sirv calls clear it scrolls the output of the other processes off the top of the screen.

@insidewhy
Copy link
Author

I can sort this out easily, just opening this issue to see if there's interest. Hope you can see the positive side of this suggestion!

@lukeed
Copy link
Owner

lukeed commented May 23, 2020

Hey there,

What is your current workaround, and how is this causing a problem?
The scroll history is preserved – it's just adjusting the viewport.

@insidewhy
Copy link
Author

@lukeed Since I'm using sirv with concurrently it's annoying that the output of all my other processes gets hidden every time sirv restarts. I have to keep scrolling which is just annoying and unnecessary. I could pass the output of sirv through sed I guess, to filter out the control code.

@lukeed
Copy link
Owner

lukeed commented Jun 1, 2020

I forgot to mention last time: passing --quiet will prevent the scroll clear. Is that sufficient for you?

Since you're restarting a server, presumably you don't need to see the start-up banner again & again. And if you have a process watcher anyway, you're already getting start/stop signals in your process-manager's logs.

My hesitation is that it feels very very silly to add a flag just to stop clearing; especially when this use case generally prefers hiding all other console noise too (aka, quiet).

@insidewhy
Copy link
Author

I guess that's better, I don't really need the access logs. It might be nice to have a --no-header for people that do but ah well.

@lukeed
Copy link
Owner

lukeed commented Jun 3, 2020

Cool. I hear where you're coming from, but my recommendation for all production servers is to run with --quiet – this is especially true in your case. There's significant performance advantages in doing so.

The documentation will start including this recommendation, too

@insidewhy
Copy link
Author

This problem is happening in development mode rather than production mode for me, where the server logs could possibly be useful, but I can live without them for now.

@itsMapleLeaf
Copy link

I'm fine with using --quiet in production, but the logs and the printed URLs are really helpful to have in dev, and as previously stated, clearing the screen ends up removing previous logs from other concurrent processes. Can we re-open this?

@insidewhy insidewhy reopened this Jun 29, 2020
@lukeed lukeed closed this as completed in 32a6a2c Jun 29, 2020
@lukeed
Copy link
Owner

lukeed commented Jun 29, 2020

Starting with sirv-cli@1.0.3 you can pass the --no-clear flag to prevent the clear() call from happening.

No other variants will work and it's purposefully unlisted. These are both intentional :)

@OJFord
Copy link

OJFord commented Sep 29, 2020

IMO this is a very surprising default, goes completely against expectation (I've never known anything else do this) what's the reason for it, just to clear those few 'header' lines? That's not worth it to me to also clearing everything else previously on screen, I find it very jarring.

@lukeed
Copy link
Owner

lukeed commented Sep 29, 2020

There are a number of things that do this, especially file servers. I much prefer this, in this case. And now it's easy to disable.

@lukeed
Copy link
Owner

lukeed commented Oct 19, 2020

Somewhat related: You can now hide only the logs (keeping the "application is running" text) via the --no-logs flag starting with sirv-cli@1.0.8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants