VM

vm-pipe-message-to-command gives: Command 'foo' produced no output

Bug #987549 reported by John Hein on 2012-04-23
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
VM
Medium
Uday Reddy

Bug Description

Rev 1355 on the trunk introduced new behavior for vm-pipe-message-to-command. It produces "Command 'foo' produced no output".

Workaround: mark the message (e.g., with M M) and invoke vm-next-command-uses-marks (M N) before vm-pipe-message-to-command. That doesn't work well if you want to operate on just the current message.

Are you sure it was in rev. 1355? I don't see any changes in 1355 that
could have caused it. Moreover, I recall seeing that message for ages, even
in Kyle Jones's releases.

Why is it a bug, anyway?

Cheers,
Uday

John Hein (xpqheqdvq4) wrote :

Works with 1354.
'no output' with 1355.

Manually reverting this hunk when using 1355 makes it "work" again...

<pre>
--- lisp/vm-save.el 2012-02-05 17:09:18 +0000
+++ lisp/vm-save.el 2012-02-12 20:29:09 +0000
@@ -645,7 +645,7 @@
        (pop-up-windows (and pop-up-windows (eq vm-mutable-window-configuration t)))
        ;; prefix arg doesn't have "normal" meaning here, so only call
        ;; vm-select-operable-messages for marks and threads.
- (mlist (vm-select-operable-messages 1 (vm-interactive-p) "Pipe")))
+ (mlist (vm-select-operable-messages 0 (vm-interactive-p) "Pipe")))
     (vm-retrieve-operable-messages 1 mlist)
     (save-excursion
       (set-buffer buffer)
</pre>

All the versions I've tried over the years have been happy to pipe the current message to a command. Since that's a sparse mapping, it may be that some other versions produced 'no output' but none that I recall.

It looks like the "produced no output" message was introduced in revision
454, way back when. See vm-save.el. It is likely that it didn't fire due
to some other bug and, when that was fixed, it started firing again.

In any case, why should this message be blocked?

Cheers,
Uday

John Hein (xpqheqdvq4) wrote :

Sorry if I wasn't clear. It's not the message that is a problem except that it's unfortunately quite accurate. It really is producing _no output_ because, well, the command is not being invoked at all.

Try, for instance, '| | wc' to see what I mean.

Uday Reddy (reddyuday) on 2012-08-21
Changed in vm:
status: New → Triaged
milestone: none → 8.2.0b1
Uday Reddy (reddyuday) on 2012-12-10
Changed in vm:
importance: Undecided → Medium
Uday Reddy (reddyuday) wrote :

John, if you are still having this problem, can you please do M-x vm-submit-bug-report? I am not able to reproduce it.

Changed in vm:
status: Triaged → Incomplete
John Hein (xpqheqdvq4) wrote :

Fixed somewhere between revno 1450 (has bug) & 1460 (doesn't have bug).

John Hein (xpqheqdvq4) wrote :

1457 has bug, 1458 doesn't

John Hein (xpqheqdvq4) wrote :

fixed on trunk in revno 1458

Changed in vm:
status: Incomplete → Fix Committed
John Hein (xpqheqdvq4) wrote :

So it was the addition of the check for (= prefix 0) in vm-select-operable-messages in vm-folder.el (revno 1458) that fixes this bug.

John Hein (xpqheqdvq4) wrote :

Hmm... but now it tries to run the command many times. Still a bug, but different symptoms now.

Changed in vm:
status: Fix Committed → In Progress
John Hein (xpqheqdvq4) wrote :

Never mind, it doesn't do that behavior (running the command multiple times) in revno 1476.

Changed in vm:
status: In Progress → Fix Committed
Uday Reddy (reddyuday) wrote :

Well, it was really fixed in rev. 1461 when I did a general scan of all calls to vm-select-operable-messages.

It is firmly fixed now.

Changed in vm:
assignee: nobody → Uday Reddy (reddyuday)
Uday Reddy (reddyuday) on 2016-10-28
Changed in vm:
milestone: 8.2.2a → 8.2.1a
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers