Command-line diff tool
Clash Royale CLAN TAG#URR8PPP
So we all have the diff
command installed by default. I certainly don't know how to use it well. But I would expect some reasonable default usage. But when I type diff file1 file2
I get ... a text ... which I have to parse in my head ... which is not helped by the fact that this is a weird combination of two texts, which are in turn very complex themselves.
So I looked for a graphical solution, e.g. meld
. That works much much better out of the box.
Yet I would prefer to have the luxury of staying on the command line all the time. Is there a fairly standard command which:
- uses colour by default and can adopt syntax highlighting
- presents side-by-side diffs and does 3-way merges by default
- works on the command line, e.g. via
libncurses
- depends on neither
vim
,emacs
nor an IDE - can modify edited files in place?
If not, why not? I looked into colordiff
but it doesn't quite cut it.
command-line diff programming merge ncurses
add a comment |
So we all have the diff
command installed by default. I certainly don't know how to use it well. But I would expect some reasonable default usage. But when I type diff file1 file2
I get ... a text ... which I have to parse in my head ... which is not helped by the fact that this is a weird combination of two texts, which are in turn very complex themselves.
So I looked for a graphical solution, e.g. meld
. That works much much better out of the box.
Yet I would prefer to have the luxury of staying on the command line all the time. Is there a fairly standard command which:
- uses colour by default and can adopt syntax highlighting
- presents side-by-side diffs and does 3-way merges by default
- works on the command line, e.g. via
libncurses
- depends on neither
vim
,emacs
nor an IDE - can modify edited files in place?
If not, why not? I looked into colordiff
but it doesn't quite cut it.
command-line diff programming merge ncurses
1
vimdiff
does exactly what you want (except for your constraint on not depending on vim.) I guess alternative tools do not exist since there are already tools (based on the editors) that do the job well. (They're not as user friendly asmeld
, but usually the crowd sticking to the terminal will prefer power over user friendliness, therefore build their tools on Vim!)
– filbranden
Feb 5 at 15:30
4
Using--unified
option makes the diff output much more readable.
– wurtel
Feb 5 at 15:34
1
sdiff with the -o option will do an interactive merge to a third file, but it doesn't do syntax highlighting nor in-place editing.
– L. Scott Johnson
Feb 5 at 15:46
add a comment |
So we all have the diff
command installed by default. I certainly don't know how to use it well. But I would expect some reasonable default usage. But when I type diff file1 file2
I get ... a text ... which I have to parse in my head ... which is not helped by the fact that this is a weird combination of two texts, which are in turn very complex themselves.
So I looked for a graphical solution, e.g. meld
. That works much much better out of the box.
Yet I would prefer to have the luxury of staying on the command line all the time. Is there a fairly standard command which:
- uses colour by default and can adopt syntax highlighting
- presents side-by-side diffs and does 3-way merges by default
- works on the command line, e.g. via
libncurses
- depends on neither
vim
,emacs
nor an IDE - can modify edited files in place?
If not, why not? I looked into colordiff
but it doesn't quite cut it.
command-line diff programming merge ncurses
So we all have the diff
command installed by default. I certainly don't know how to use it well. But I would expect some reasonable default usage. But when I type diff file1 file2
I get ... a text ... which I have to parse in my head ... which is not helped by the fact that this is a weird combination of two texts, which are in turn very complex themselves.
So I looked for a graphical solution, e.g. meld
. That works much much better out of the box.
Yet I would prefer to have the luxury of staying on the command line all the time. Is there a fairly standard command which:
- uses colour by default and can adopt syntax highlighting
- presents side-by-side diffs and does 3-way merges by default
- works on the command line, e.g. via
libncurses
- depends on neither
vim
,emacs
nor an IDE - can modify edited files in place?
If not, why not? I looked into colordiff
but it doesn't quite cut it.
command-line diff programming merge ncurses
command-line diff programming merge ncurses
edited Feb 6 at 6:25
Jürgen
192110
192110
asked Feb 5 at 15:02
VoracVorac
1,02621833
1,02621833
1
vimdiff
does exactly what you want (except for your constraint on not depending on vim.) I guess alternative tools do not exist since there are already tools (based on the editors) that do the job well. (They're not as user friendly asmeld
, but usually the crowd sticking to the terminal will prefer power over user friendliness, therefore build their tools on Vim!)
– filbranden
Feb 5 at 15:30
4
Using--unified
option makes the diff output much more readable.
– wurtel
Feb 5 at 15:34
1
sdiff with the -o option will do an interactive merge to a third file, but it doesn't do syntax highlighting nor in-place editing.
– L. Scott Johnson
Feb 5 at 15:46
add a comment |
1
vimdiff
does exactly what you want (except for your constraint on not depending on vim.) I guess alternative tools do not exist since there are already tools (based on the editors) that do the job well. (They're not as user friendly asmeld
, but usually the crowd sticking to the terminal will prefer power over user friendliness, therefore build their tools on Vim!)
– filbranden
Feb 5 at 15:30
4
Using--unified
option makes the diff output much more readable.
– wurtel
Feb 5 at 15:34
1
sdiff with the -o option will do an interactive merge to a third file, but it doesn't do syntax highlighting nor in-place editing.
– L. Scott Johnson
Feb 5 at 15:46
1
1
vimdiff
does exactly what you want (except for your constraint on not depending on vim.) I guess alternative tools do not exist since there are already tools (based on the editors) that do the job well. (They're not as user friendly as meld
, but usually the crowd sticking to the terminal will prefer power over user friendliness, therefore build their tools on Vim!)– filbranden
Feb 5 at 15:30
vimdiff
does exactly what you want (except for your constraint on not depending on vim.) I guess alternative tools do not exist since there are already tools (based on the editors) that do the job well. (They're not as user friendly as meld
, but usually the crowd sticking to the terminal will prefer power over user friendliness, therefore build their tools on Vim!)– filbranden
Feb 5 at 15:30
4
4
Using
--unified
option makes the diff output much more readable.– wurtel
Feb 5 at 15:34
Using
--unified
option makes the diff output much more readable.– wurtel
Feb 5 at 15:34
1
1
sdiff with the -o option will do an interactive merge to a third file, but it doesn't do syntax highlighting nor in-place editing.
– L. Scott Johnson
Feb 5 at 15:46
sdiff with the -o option will do an interactive merge to a third file, but it doesn't do syntax highlighting nor in-place editing.
– L. Scott Johnson
Feb 5 at 15:46
add a comment |
1 Answer
1
active
oldest
votes
I fear that this answer will not satisfy you, but I think that you pose conflicting constraints.
About diff
But first I have to defend the classical diff tool: Its main purpose is to generate software patches that are supposed to be processed by machines on application. In addition, these patches are designed to be as compact as possible and to ideally use only ASCII characters, so that they can be shared fast and reliably via e-mail, Usenet, etc.
That these patches can be read by humans (and understood by some humans) is also an important property, but not top priority.
Your question
I fully understand and share your desire for simple and elementary command line tools, but a side by side diff, possibly with color highlighting, is neither simple nor does it lie within the scope what we can expect from a real command line tool, simply because it is not line orientated any more.
What comes next to it are Vi or Emacs based tools, which are as simple and clear for human reception as it can be, being highly flexible at the same time. They also offer powerful merging capabilities.
Form those, vimdiff
was already mentioned in the comments.
Concerning Emacs, file comparisons are typically started from within the editor. The most commonly used tool for that is Ediff, which offers umpteen entry points that correspond to the various needs: comparison of two files, tree files, one of them treated as a common ancestor, and so on. The same with possible merges.
Albeit unusual, I rigged up an access to Ediff from the command line: If you start Emacs with
emacs FILE1 FILE2 -nw --eval "(apply 'ediff-buffers (last (nreverse (buffer-list)) 2))"
then you jump directly in an interactive Ediff session that compares FILE1
and FILE2
within your terminal. If you omit the -nw
option (and all requirements are met), you get the same session in a separate graphical frame. See also this related question by ashutosh jain.
Okay, I would not go so far to call Emacs an easy tool. But if you study it thoroughly for some years, you will love it. (Personal opinion.)
So, unfortunately no: I do not know any tool that meets all of your constraints.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f498815%2fcommand-line-diff-tool%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I fear that this answer will not satisfy you, but I think that you pose conflicting constraints.
About diff
But first I have to defend the classical diff tool: Its main purpose is to generate software patches that are supposed to be processed by machines on application. In addition, these patches are designed to be as compact as possible and to ideally use only ASCII characters, so that they can be shared fast and reliably via e-mail, Usenet, etc.
That these patches can be read by humans (and understood by some humans) is also an important property, but not top priority.
Your question
I fully understand and share your desire for simple and elementary command line tools, but a side by side diff, possibly with color highlighting, is neither simple nor does it lie within the scope what we can expect from a real command line tool, simply because it is not line orientated any more.
What comes next to it are Vi or Emacs based tools, which are as simple and clear for human reception as it can be, being highly flexible at the same time. They also offer powerful merging capabilities.
Form those, vimdiff
was already mentioned in the comments.
Concerning Emacs, file comparisons are typically started from within the editor. The most commonly used tool for that is Ediff, which offers umpteen entry points that correspond to the various needs: comparison of two files, tree files, one of them treated as a common ancestor, and so on. The same with possible merges.
Albeit unusual, I rigged up an access to Ediff from the command line: If you start Emacs with
emacs FILE1 FILE2 -nw --eval "(apply 'ediff-buffers (last (nreverse (buffer-list)) 2))"
then you jump directly in an interactive Ediff session that compares FILE1
and FILE2
within your terminal. If you omit the -nw
option (and all requirements are met), you get the same session in a separate graphical frame. See also this related question by ashutosh jain.
Okay, I would not go so far to call Emacs an easy tool. But if you study it thoroughly for some years, you will love it. (Personal opinion.)
So, unfortunately no: I do not know any tool that meets all of your constraints.
add a comment |
I fear that this answer will not satisfy you, but I think that you pose conflicting constraints.
About diff
But first I have to defend the classical diff tool: Its main purpose is to generate software patches that are supposed to be processed by machines on application. In addition, these patches are designed to be as compact as possible and to ideally use only ASCII characters, so that they can be shared fast and reliably via e-mail, Usenet, etc.
That these patches can be read by humans (and understood by some humans) is also an important property, but not top priority.
Your question
I fully understand and share your desire for simple and elementary command line tools, but a side by side diff, possibly with color highlighting, is neither simple nor does it lie within the scope what we can expect from a real command line tool, simply because it is not line orientated any more.
What comes next to it are Vi or Emacs based tools, which are as simple and clear for human reception as it can be, being highly flexible at the same time. They also offer powerful merging capabilities.
Form those, vimdiff
was already mentioned in the comments.
Concerning Emacs, file comparisons are typically started from within the editor. The most commonly used tool for that is Ediff, which offers umpteen entry points that correspond to the various needs: comparison of two files, tree files, one of them treated as a common ancestor, and so on. The same with possible merges.
Albeit unusual, I rigged up an access to Ediff from the command line: If you start Emacs with
emacs FILE1 FILE2 -nw --eval "(apply 'ediff-buffers (last (nreverse (buffer-list)) 2))"
then you jump directly in an interactive Ediff session that compares FILE1
and FILE2
within your terminal. If you omit the -nw
option (and all requirements are met), you get the same session in a separate graphical frame. See also this related question by ashutosh jain.
Okay, I would not go so far to call Emacs an easy tool. But if you study it thoroughly for some years, you will love it. (Personal opinion.)
So, unfortunately no: I do not know any tool that meets all of your constraints.
add a comment |
I fear that this answer will not satisfy you, but I think that you pose conflicting constraints.
About diff
But first I have to defend the classical diff tool: Its main purpose is to generate software patches that are supposed to be processed by machines on application. In addition, these patches are designed to be as compact as possible and to ideally use only ASCII characters, so that they can be shared fast and reliably via e-mail, Usenet, etc.
That these patches can be read by humans (and understood by some humans) is also an important property, but not top priority.
Your question
I fully understand and share your desire for simple and elementary command line tools, but a side by side diff, possibly with color highlighting, is neither simple nor does it lie within the scope what we can expect from a real command line tool, simply because it is not line orientated any more.
What comes next to it are Vi or Emacs based tools, which are as simple and clear for human reception as it can be, being highly flexible at the same time. They also offer powerful merging capabilities.
Form those, vimdiff
was already mentioned in the comments.
Concerning Emacs, file comparisons are typically started from within the editor. The most commonly used tool for that is Ediff, which offers umpteen entry points that correspond to the various needs: comparison of two files, tree files, one of them treated as a common ancestor, and so on. The same with possible merges.
Albeit unusual, I rigged up an access to Ediff from the command line: If you start Emacs with
emacs FILE1 FILE2 -nw --eval "(apply 'ediff-buffers (last (nreverse (buffer-list)) 2))"
then you jump directly in an interactive Ediff session that compares FILE1
and FILE2
within your terminal. If you omit the -nw
option (and all requirements are met), you get the same session in a separate graphical frame. See also this related question by ashutosh jain.
Okay, I would not go so far to call Emacs an easy tool. But if you study it thoroughly for some years, you will love it. (Personal opinion.)
So, unfortunately no: I do not know any tool that meets all of your constraints.
I fear that this answer will not satisfy you, but I think that you pose conflicting constraints.
About diff
But first I have to defend the classical diff tool: Its main purpose is to generate software patches that are supposed to be processed by machines on application. In addition, these patches are designed to be as compact as possible and to ideally use only ASCII characters, so that they can be shared fast and reliably via e-mail, Usenet, etc.
That these patches can be read by humans (and understood by some humans) is also an important property, but not top priority.
Your question
I fully understand and share your desire for simple and elementary command line tools, but a side by side diff, possibly with color highlighting, is neither simple nor does it lie within the scope what we can expect from a real command line tool, simply because it is not line orientated any more.
What comes next to it are Vi or Emacs based tools, which are as simple and clear for human reception as it can be, being highly flexible at the same time. They also offer powerful merging capabilities.
Form those, vimdiff
was already mentioned in the comments.
Concerning Emacs, file comparisons are typically started from within the editor. The most commonly used tool for that is Ediff, which offers umpteen entry points that correspond to the various needs: comparison of two files, tree files, one of them treated as a common ancestor, and so on. The same with possible merges.
Albeit unusual, I rigged up an access to Ediff from the command line: If you start Emacs with
emacs FILE1 FILE2 -nw --eval "(apply 'ediff-buffers (last (nreverse (buffer-list)) 2))"
then you jump directly in an interactive Ediff session that compares FILE1
and FILE2
within your terminal. If you omit the -nw
option (and all requirements are met), you get the same session in a separate graphical frame. See also this related question by ashutosh jain.
Okay, I would not go so far to call Emacs an easy tool. But if you study it thoroughly for some years, you will love it. (Personal opinion.)
So, unfortunately no: I do not know any tool that meets all of your constraints.
edited Feb 6 at 1:38
answered Feb 5 at 16:21
JürgenJürgen
192110
192110
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f498815%2fcommand-line-diff-tool%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
vimdiff
does exactly what you want (except for your constraint on not depending on vim.) I guess alternative tools do not exist since there are already tools (based on the editors) that do the job well. (They're not as user friendly asmeld
, but usually the crowd sticking to the terminal will prefer power over user friendliness, therefore build their tools on Vim!)– filbranden
Feb 5 at 15:30
4
Using
--unified
option makes the diff output much more readable.– wurtel
Feb 5 at 15:34
1
sdiff with the -o option will do an interactive merge to a third file, but it doesn't do syntax highlighting nor in-place editing.
– L. Scott Johnson
Feb 5 at 15:46