CMD on Win10 going away

announce
1

… can we please think about fixing the console output when using Meteor in Powershell?

Or: http://aka.ms/qhkv2c for Insiders.

Basically, whenever I use Meteor with Powershell I run into two bugs:
a) All the output gets routed to one dinky line at the top of the window, making it impossible to read status updates.
b) If an error happens, it’s either in a blue font (Powershell’s default background colour is also blue) or I only get the timestamps for the error message - but not the actual messages themselves.

This will be an issue for Windows Insiders right now. For everyone else, this will be an issue early next year when the next big update drops.

So, @sashko, could we please revive efforts to fix this annoying issue? Because otherwise Meteor on Win10 will be next to unusable.

2 Likes
2

I use http://cmder.net/ which hasn’t given me any issues with meteor.

Obviously that doesn’t help you with your Powershell issues, but it might be an acceptable workaround.

3

Workarounds are nice. However, it’s an issue when your program doesn’t work out of the box.

4

Meteor command makes powershell looks very messy tho…

5

Aye, right now it’s hard to use meteor on Windows. Bash doesn’t work as expected yet (known mongo bug) and powershell has the issues you described above. Hoping for a fix for this :slight_smile:

6

Sounds like a great idea for a pull request - just clone Meteor into your windows machine, run it in powershell, find a way to change the colors, send a PR, and it will come out in the next version!

7

Yes, I already tried that route. However, the offending file console.js is, in my honest opinion, a byzantine mess which pulls in dependencies from seemingly everywhere. And those dependencies have other dependencies which in turn have dependencies on other files and so on and so forth.

When I’m doing a bughunt, I always try the clean room approach which means that I’m pulling in the minimum required amount of dependencies and then run the offending class / function through its paces. (That’s why I like Dependency Injection - it makes stuff like that a breeze).

I cannot do that with your console.js which means that I have to run the entire program which makes it a bit of a headache to figure out where it’s going wrong. As you yourself have found out.

I’d really like to take a scalpel to this file and annihilate everything in it which does not have anything to do with actually creating a console output.

It isn’t made easier by the fact that you chose to pull in node modules dynamically.

I’ll have a look into it regardless.

8

Okay, this will be slow going. For instance, this is the beginning of a function which actually prints something to the console:

_print: function(level, message) {
    var self = this;

    // We need to hide the progress bar/spinner before printing the message
    var progressDisplay = self._progressDisplay;
    progressDisplay.depaint();

So I went out there and had a look at what this progressDisplay actually does when it depaint()s

// No-op progress display, that means we don't have to handle the 'no progress
// display' case
var ProgressDisplayNone = function () {
};

_.extend(ProgressDisplayNone.prototype, {
  depaint: function () {
    // No-op
  },

  repaint: function () {
    // No-op
  }
});

It’s a no-op. Can anyone enlighten me why this is even there in the first place?

1 Like
9

I think I found the issue, though.

1 Like
10

Honestly if you can delete most of Console.js while keeping the current functionality that might be awesome. I’d check in with @benjamn or @abernix first though to see if there is any good reason not to do it.

11

Naw, I definitely found the issue. 'twas a very easy one once I found out what was going on.

Let me put it this way:

new Array(249).join('\b')

is definitely not a good idea for a carriage return in PowerShell.

1 Like
12

Sounds like that could definitely be the root of the issue!

13

I tested my change (which basically just checks if we’re running PS) and it works fine in CMD, PowerShell and PowerShell in Legacy Mode. I also submitted a Pull Request, so, we’ll see if it actually works on other machines as well.

5 Likes
14

@rhywden, good on ya for that PR – I’m sure that will be a much appreciated change. As to the explanation for the no-op in that code…

In that particular situation, yes, it is a no-op, however, ProgressDisplayNone is a type of ProgressDisplay* class which is instantiated when the progress display is initiated. There are different ways that it may be instantiated, on these lines, including:

  • ProgressDisplayFull
  • ProgressDisplayStatus
  • ProgressDisplayNone

Each of these functions can implement the repaint method however they wish and on the None class, it holds true to its name and does, well, nothing. :slight_smile:

I won’t claim that the current code is the most efficient (in fact, there is actually recent evidence to indicate otherwise), but it does serve a purpose (it’s not all a no-op) and that’s my explanation for what you’ve found there.

Thanks for contributing!

1 Like
15

Just stumbled over another bug - you seem to be doing something very weird on Windows.

I’m currently trying out Typescript and the “official” Typescript compiler absolutely insisted on compiling this:

import {Meteor} from "meteor/meteor";
var foo = Meteor.user();

into this:

var meteor_1 = require('meteor/meteor'); 

var foo = meteor_1.Meteor.user();

which then obviously crashed because the function user() does not exist on that particular object.

Since I had goofed around with various packages, I then decided to revert everything back to the latest commit by doing:

git reset --hard
git clean -fxd

The last command cleans out everything, i.e. normally ignored/untracked files.

However, this also somehow tracks back to the Meteor installation directory which then leads to the following error message:

C:\reponame> meteor
The system cannot find the required path

which in turn necessitates a complete re-install.

16

Not sure who “you” is in this context. If you’d like to help improve the project, great, but let’s not point fingers. It’s a community project and I am a member of the community. Many folks use Meteor (and TypeScript) on Windows, so there could be a problem with your implementation. Your help with improving anything you run into with is greatly appreciated. :slight_smile:

There is no problem with the code that it transpiled it into. In fact, it makes a lot of sense. Let’s look at the import:

import {Meteor} from "meteor/meteor";

This is ES6 code and depending on the engine which uses it needs to be compiled. Due to various differences in Node capabilities, this means transpiling to a different, compatible version of ECMAScript. During this process, this import statement needs to be changed to CommonJS (the module system used in Node).

To explain why that code is transpiled that way, you’ll note that you are asking for the Meteor named-export from the meteor/meteor package. This equates to require("meteor/meteor").Meteor in the CommonJS format, which is exactly what the code that you provided is doing, albeit with different variable names and a slightly more re-usable format.

No, it does exist, but you may be using it incorrectly. Hard to say though as you didn’t include an error.

Though before you suggest that you are using it correctly, I’ll point out that I don’t see a lot of reasons why using Meteor.user() in the global scope like that would be what you want. At that level, it would be evaluated during initialization – meaning, before there is actually any chance of a user, or in the case of the server, outside of an authenticated method/publication, etc. Have you tried using it inside a context where there would be a user?

I would recommend trying to run something like the Todos app to see how it is intended to work. By starting with a template, you’ll gain some understanding of where it’s expected to work and I think you’ll find that it works properly.

The system cannot find the required path

This issue has shown up before but I haven’t received reproduction steps which work. See this issue here. If you’re getting this error it means that the meteor command, which is outside of your app directory is missing or is no longer in your PATH.

I’m aware. And this probably explains what has happened. In case it’s not obvious, that is an extremely dangerous command, especially on Windows. You are saying “forcefully and recursively delete directories and ignore all previously ignored files”. You might be interested in this issue which outlines how git clean follows junctions and deletes their contents (though that’s not too surprising, as that’s exactly what Microsoft says would happen on commands which work recursively).

Within your app, there are various junctions (hard-links) to global installations, one of the most important being the .meteor/local/dev_bundle link. This ensures that your app matches the correct version of Meteor on your system, allows multiple versions of Meteor to co-exist without needing (large) meteor-tool installations for every app that you create. It also allows the meteor npm and meteor node commands to work on the proper versions of node binaries without relying on what could be a cluttered global installation (and likely not the correct version).

Normally, you wouldn’t have this problem because Meteor creates the proper .gitignore rule that prevents .meteor/local/dev_bundle from being included in git commands, but by adding the -x you’ve told git to ignore that. I would recommend not using the -x flag, or if you do use it, to add the -i flag to do any deletions interactively with prompts before deletion.

In all likeliness, you’ve probably deleted the meteor.bat command from %localappdata%/.meteor/packages/meteor-tool/1.4.2_3/mt-os.windows.x86_32/dev_bundle, leaving your installation broken. Imagine if you had a junction to the root of your drive!

Whew, that got long! I hope this helps to explain. I can see how this might be confusing (and painful!), but if you know of a way to prevent this, that would be great! Ultimately though, it’s probably not correct to be using git clean -x.

2 Likes
17

For me, cmder did not fix the issue of having all the output overwrite itself on a single line (Win10). However, There is an option under the Command Prompt > Properties > Options > "Use Legacy Console (requires relaunch), which did work for me.