GNU nano - Bugs: bug #27346, [Wish] add support for writing the...
You are not allowed to post comments on this tracker with your current authentication level.
bug #27346: [Wish] add support for writing the buffer contents to standard out
Submitter: | None | ||
Submitted: | Sun 30 Aug 2009 12:30:04 PM UTC | ||
Severity: | 1 - Wish | Status: | None |
Assigned to: | None | Open/Closed: | Open |
Jump to the original submission
Fri 25 Nov 2022 11:05:31 AM UTC, comment #7: |
Benno Schulenberg <bens>![]() |
Wed 23 Nov 2022 04:29:03 PM UTC, comment #6: Not really a solution, but just pointing out that what is discussed here can be done using named pipes (though given the interactive nature of nano, it cannot be done within a single terminal).
|
Tasos Papastylianou <tpapastylianou> |
Mon 04 Jan 2021 02:20:14 PM UTC, comment #5: This is a great feature! I don't see any disadvantages to implementing it (other than a few lines of code added).
|
Peter Passchier <pepa65> |
Wed 11 Nov 2020 03:08:00 PM UTC, comment #4: Doesn't really work: both the decoding and the encoding ask for the password -- that is too confusing. It should ask for the password just once, but I don't know how to arrange that. |
Benno Schulenberg <bens>![]() |
Thu 08 Oct 2020 06:23:32 PM UTC, comment #3: Here's a first implementation of the feature. |
Benno Schulenberg <bens>![]() |
Mon 08 Aug 2016 03:35:24 PM UTC, comment #2: It is already possible to read in the output of a decryption command by using the "read from standard input" feature. For example: 'gpg --decrypt safebox.asc | nano -'. But there is no way to encrypt this again without using a temporary file on disk. What is needed is an option to tell nano to write the buffer contents not to a file but to standard output. That doesn't look easy to make. I don't even know if it's possible. |
Benno Schulenberg <bens>![]() |
Sat 14 Jun 2014 04:41:03 PM UTC, comment #1: I have no comprehension of GPG, but would the new --noread option be of any use to you? (Available from nano-2.3.3 onward.) |
Benno Schulenberg <bens>![]() |
Sun 30 Aug 2009 12:30:04 PM UTC, original submission:
Hello,
|
Anonymous |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 10 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-11-25 | bens | Attached File | - | ![]() |
Added 0001-tentative-feature-allow-piping-the-buffer-to-standar.patch, #54014 |
2022-03-14 | bens | Summary | [Request] add support for writing the buffer contents to standard out | ![]() |
[Wish] add support for writing the buffer contents to standard out |
2020-11-11 | bens | Status | In Progress | ![]() |
None |
Assigned to | bens | ![]() |
None | ||
2020-10-08 | bens | Attached File | - | ![]() |
Added 0001-possible-new-feature-allow-piping-out-the-buffer-via.patch, #49944 |
Status | None | ![]() |
In Progress | ||
Assigned to | None | ![]() |
bens | ||
2016-08-08 | bens | Summary | [Request] add support for editing files encrypted with GPG or CCrypt | ![]() |
[Request] add support for writing the buffer contents to standard out |
2014-06-14 | bens | Severity | 3 - Normal | ![]() |
1 - Wish |
Summary | [Feature request] Add support for editing files encrypted with GPG or CCrypt | ![]() |
[Request] add support for editing files encrypted with GPG or CCrypt |
Using a named pipe would also work for editing GPG-encrypted data, but having to use two terminals isn't really user friendly.
So, with the patch (attached, updated for current git), the following should allow decrypting, editing, and re-encrypting a file in basically a single command:
This should ask for the passphrase (for the decrypting) just once, as encrypting does not require the passphrase.
It is rather weird, though, that typing ^S or ^O will immediately exit from nano. (The patch could be improved to make ^X do the same thing, instead of inappropriately asking for a filename.)
(file #54014)